Saturday, December 15, 2007

Iterating properly in Python

After more than a year of python hacking you take a look at the official Python tutorial and still discover new ways of enhancing your code. Just two ways of saving list constructions on our actual code.

The first one: In our code, we are currently doing all the time something like this:

for key, value in myDictionary.items() :

This is not that appropiate because it creates the tuple list and then iterates. But if you do:

for key, value in myDictionary.iteritems() :

You just get fetched keys and values without creating any temporary list.

The other thing our code is full of is constructing a list using list comprehensions:

tempList = [expresionUsing(item) for item in collection]
for item in tempList: doWhatEverWith(item)

I knew about list comprehensions and i knew about generator functions. Generator functions are functions can be a iteration source by doing yield instead of return. yield returns a value but keeps the function execution state for the next call. That is a very interesting feature but i never used it because it is harder to create a function that yields than to create the loop itself.

But by reading the tutorial i found a brand new kind of expressions that sum up list comprehensions and generator functions: generator expressions. They have the same syntax than list comprehensions using parethesis instead of brackets, but instead of creating a list they create a source of iteration so that no temp lists are created. Previous code would look like that:

iterable = (expresionUsing(item) for item in collection)
for item in iterable: doWhatEverWith(item)

There are plenty of places in the code we generated last year (WiKo, TestFarm and build and utility scripts in CLAM where we can apply those two ideas. So i am pretty happy on having discovered that.

Thursday, December 6, 2007

Command of the day: svk ls

Why not calling them command-of-the-year as the one and only command-of-the-day i posted until now was posted one year ago? Well, they are intended to be commands that saved me the day like the one i explain today.

On my previous entry, I explained that Pau and me were publishing on sourceforge a python script, WiKo, that we used to edit our latest articles and thesis. Because we used it in such context, latest version have been commited in a private repository we have for articles and the like.

I wanted to move the files to a public repository at sourceforge. Sadly, svnadmin dump just works when you are in the same host as the repository is and we have no regular ssh access to the subversion. We could bother our admin, Jordi Funollet, but he is always very busy and we are always requesting him. (Thanks, Jordi for your support!!)

Luckily i found a nice entry blog on how to use svk to remotely dump a svn repository.

You need to install svk, in debian based:

 sudo apt-get install svk 

Then we should create a mirror repository with svk just containing the revisions concerning the selected path

 svk ls svn+ssh:// 

svk will ask you several questions:

  • Choose a base URI to mirror from (press enter to use the full URI): To filter by path, i recommend to do such filtering on the command line by specifying the full path, so return.
  • Depot path: [//mirror/wiko] Is very important here to change the depot name so you can skip that '//mirror' part, so answer //yourproject beginning with a double slash!!
  • To end up, it asks which revisions do you want, normally the answer is 'a' (all)

Then dump the local svk repository:

 svnadmin dump ~/.svk/local > my-repository-dump 

And now you can import it into sourceforge as normal:

 svnadmin load [the-new-repository]  < my-reposotory-dump 

With sourceforge the process is more complex. You should upload the dumpfile to the shell server. For example, for wiko it was at: s

Then you should specify the uploaded dump file as it was a cvs to svn migration. It last a while, after that you can checkout wiko code!

 svn co 

I lost the history of the file before a move operation, but at least we recovered some of the history.

Taking a look at the man page you can see that svk is really helpfull for other purposes, but definitely, its ability of dumping a remote repository saved my day :-)

WiKo, the wiki compiler

Pau and me have just released WiKo as sourceforge project. WiKo is a simple but powerful Python script that takes files with wiki content on a given directory and either builds a web, a LaTeX article or a blog.

The script has a very long history before being branded as WiKo. It has its roots on the simple script i did to build most of my websites (Can Voki, Codders, KKEPerians UNLTD...) The script eased keeping static a lot of pages sharing the same layout design. The script was later enhanced to read wiki pages and to build also LaTeX articles. Even I used it for my master thesis. Recently Pau also started to use it for his PhD thesis and he has added great improvements such as LaTeX formulas in HTML output or bibliography linking. And lately we started to use it as internal wiki for some projects we are involved within Barcelona Media. So we thought that such script deserved a sourceforge project, and that's how WiKo born. I hope it can be useful to you all.

WiKo might be useful to you if:

  • You have an static website and you are considering to make it dynamic just to reuse design
  • You have to write articles to be available in both html and pdf
  • You are moving content from web, to LaTeX articles and to blogs and you are feed up of translating markup
  • You love wiki syntax but you hate to edit wikis in web forms
  • You like LaTeX output but you hate (or don't know) its markup
  • You like colaborative environments such subversion and want to use it as base for a wiki
  • You still are considering ikiwiki but you would like it was not written in Perl so you could contribute to it ;-)

Also I am currently working hard on being able to use WiKo to edit this blog. I am almost there so stay tunned.

Tuesday, November 6, 2007

Trolltech Developers Day

On my last entry I talked about the trip to San Francisco. Besides the GSoC mentor submit, we also joined the Trolltech developers days. The slides and examples of the Trolltech event are available online. It is worth to take a look at them although slides are not as nice as having some trolls explaining them in live.

We really learned a lot of such event: Andreas Aardal Hansen, a very smart hacker, gave us a nice lesson on how we could exploit the Graphics View framework to turn CLAM into a cooler environment. The framework has been massively adopted in just one year since it was published, and the reason is that it is just impressive how easy you can do complex and cute things on a snap. The reason why we didn't used it is because we did the full rewrite of the NetworkEditor just before Qt 4.2 which included such framework. Another rewrite at that time would have been too hard.

We also could have a little talk with Thierry Bastian who is responsible of turning KDE's Phonon multimedia interface into a regular cross platform module in Qt. Unfortunately we were still travelling the first day and we missed his talk on Phonon.

Another nice session I assisted was the one presented by Girish Ramakrishnan on Qt style sheet support. Just by taking a look at the latest demos you can realize that Qt application can be very cool and even use such style sheets to let designers enhancing the look and feel of your applications without even programming.

While I was on the style sheet presentation Pau was on the Model View talk. I thought that it was about the old Smalltalk MVC model we failed to generalize in CLAM so many times and in so many flawors. So I thought it was a mistake on the troll's side to generalized it so much, but I just took a look at the presentation, and maybe is worth a try. It seems that they did a smart twist to the pattern to make it worth to work with.

I also nagged Jason Barron, at the support team, with some bugs we found on latest Qt version and some question on how to implement some things for CLAM. I still have to get in contact with him again to get some solution for some problems.

As I said we learned a lot, and we are eager to apply such knowledge to CLAM. A month later we have just applied such knowledge to fix some QtOpenGL bugs but we are planning at some time to port the NetworkCanvas to QGraphicsView.

Monday, October 29, 2007

GSoC 2007 mentor submit

A couple of weeks ago, Pau and me were at San Francisco for the Google Summer of Code Mentor Submit. At the submit we joined some interesting sessions on how to improve the next GSoC, but also we met a lot of other hackers of free software projects all around the world: Mixxx, Inkscape, KDE, Amarok, Pidgin, Scumvm, Haiku, Crystal Space, Ogre, Moin Moin, Drupal, VideoLan, XMMS2, audacious... Well, as you can see in this picture we were pretty much people:

Family photo of GSoC 2007 mentors

I knew about most of all other projects, but, sadly, nearly no one knew about CLAM. :-( The good news is that most of them get pretty interested as they saw CLAM capabilities on audio processing and application prototyping. We need independently packaged end user tools!!

I also was glad to confirm the collaboration between projects that one could figure out being competitors:

  • People working on desktops (KDE, Gnome...) are in fact in a very close collaboration.
  • Wiki implementations (Moin Moin, Wikimedia...) meet there
  • Also several 3D engines (Crystal Space, Ogre...) met there
  • Comunity portals such as Drupal, Joomla, Plone...

They all share common challenges and solutions and they used the submit to join efforts.

Related to common issues and efforts, we took a very productive meeting on multiplatform development where some multiplatform projects, including us, shared experiences. We explained how we faced such problem at CLAM: the use of portable 3rd party libraries, crosscompiling from Linux to other platforms, and the use of testfarm to rapidly detect multiplatform issues. Some projects, such VideoLan had automated third party compilation scripts a step we have not automated at all. We realized that a lot of people was also solving such problems and we compromised to share experiences and results. For example, we talked about having a single repository of precompiled binaries of third party libraries. We also realized about our not-so-open-source mind we most of us realized that we were not reporting back patches we did to external libraries. We compromised to send them to upstream or making them available in a common place for the other project using them.

Friday, July 20, 2007

Simplifying Spectral processing in CLAM

Current CLAM Spectrum implementation has four different internal representations: Complex array, polar array, separated magnitude and phase buffers, and separated magnitude and phase break point functions (point controled envelopes). Conversion and synchronization among such representations were handled by the Spectrum class itself and this was intended to be transparent. But processing algorithms had to know which representations were already present to trade off between doing conversion and applying different versions of a given algorithm depending on the representation.

For instance, spectrum product in polar representation is cheaper by itself than complex product, but if you have to convert incoming or outcomming spectrums it migth be not so cheap. What about having two different representations for each operand? Which one should be converted? Output format could be a discriminant but do the module has information to know which is the convenient output representation? Such decissions make the implemention of processings using spectrums really complex.

Besides that, algorithms also had to consider different cases for different scales (linear or dB). So the complexity of processing objects having to deal with spectra is very high. A lot of code dealt with querying the presence of a given representation or synchronizing them.

So, we decided to simplify all that by having several kind of spectrum for each representation and doing any representation change explicit by a converter processing. We are currently considering just two spectrum classes: MagPhaseSpectrum and ComplexSpectrum. We added also converters to the current Spectrum to enable progressive migration. The implementation of FFT and IFFT was highly simplified as we don't need to deal with conversions and prototypes configuration, just to input or output complex spectra.

This is a setup of a system which perform complex and polar products of two spectra:

The spectral product has been simplified. Now we have a product for each kind of spectrum in contrast with the previous situation where we had a single module containing implementations for every combinations of inputs.

Code is really simpler to understand and write this way. After having all that we could do a profiling on comparing which is best, conversions and cheap product or no conversions and expensive product. The option without conversions won but the situation can change on the future depending on the optimizations we could do on the conversion. Having the processing modules factored that way we could change them and doing the benchmark that easy.

In the process of takin such decission we noticed that some elementary CLAM elements such as the AudioSource, AudioSink and specially AudioMixer were taking too much CPU.

After fixing that we got a clear profile that highlights which is the proper strategy for spectrum product for our concrete case. Callgrind is a really nice tool:

So I hope we can move soon to that new way of doing spectral processing in CLAM but still a lot of code must be updated.

Monday, July 2, 2007

CLAM Plugins

One of the most interesting features of the upcomming CLAM release will be a plugin system that will allow users to add their own processings as a plugin to any CLAM based application.
Just by placing a library on a given folder.

We provide some cute tutorials on writting simple processings from scratch, and a SConstruct file that will compile and install everything in a given folder as a plugin.

It has been more easy than we thought as we were frightened by Visual 'mecatxis' and we just dropped it. A single class did the work. There is still some work to do on documenting the registration of the configuration dialogs for the processings and making the Processing Tree of the network editor to populate automatically from the factory content.

The former can be done very quick by adding the Qt4 configurator as a CLAM library, but we want to provide a more general solution not requiring users linking against Qt4. The later (processing tree population) is something Andreas Calvo is working with. And he is doing nice progresses.

Deprecating Windows as development platform

In this entry i will explain how we got ride of Windows as development platform for the CLAM project still providing Windows binaries by using the tandem mingw32 (for Linux) and Wine. We dealt with crosscompilation of most of CLAM dependencies such as Portaudio, Asio, libsndfile, liboggvorbis, pthreads, fftw3, libmad, id3lib, XercesC, libxml++, NSIS and Py2Exe.

After a very dissapointing and fustrating effort from Pau and me of trying to have a reproducible build environment for CLAM based on Visual Express 2005, we decided that the whole thing was foolish and decided give mingw a try.

I am proud of not having a Windows box available at home ;-) but that doesn't mean i cannot contribute to that part of the development so the last days i did an spike on having mingw crosscompiling CLAM from Linux! We succeeded to compile it all, the dependencies, CLAM and the applications. Because some dll conflicts when installing that could not go into the 1.1.0 version of CLAM. After a gutsy update we could compile it all,
so expect rewamped windows binaries for the next release... and maybe development binaries. You can already give a try to the latest svn snapshots.

The key point has been using Wine to install with their own windows installers some libraries and tools such as Qt4, GTK (for pkg-config, libxml++ and dependencies), and NSIS to build windows installers from Linux!

Wine and mingw are a great tandem to compile and test the binaries. Also SConstruct has been a nice tool to hack a quick build environment for third party libraries when the one provided (normally based on autotools) was too messy to get on with.

We kept a reproducible log of the mingw crosscompilation at the clam wiki. This includes how to get all the dependencies working, which may be usefull for you own project. CLAM dependencies we addressed were: Portaudio, Asio, libsndfile, liboggvorbis, pthreads, fftw3, libmad, id3lib, XercesC, libxml++, NSIS and Py2Exe.

Wednesday, April 18, 2007

Enhancing QSynth/Rosegarden/SonicVisualizer knobs for CLAM

I am still expanding the widgets toolbox for CLAM.

PK Widgets, the ones in my previos blog entry, are really nice but they don't integrate well with other widgets because the background and the fixed size. So you have to do a mostly PK interface or not. Most standard Qt widgets look nice with a nice theme such plastique, but for some reason QDial is the ugly duck of the collection... well, according Chris Cannam, also QLCD. I agree with him. QDial looks like old CDE style in every style you choose:

Besides the look, QDial behaviour is far from optimal. Clicking on any point jumps the pointer which is a bad thing if you want to progressively control a parameter. Also when you move the knob beyond one of the extremes you may switch sharply to the other extreme. Using such a mischievous control in a live performance could be a disaster. So let's look for asthetic and behavioral alternatives.

Going back to the look, I just liked a lot the knobs in QSynth a program by Rui Nuno Capella.

The knobs indeed were taken from Rosegarden and Pedro Lopez Cabanillas enhanced the look by adding some nice but expensive gradients. The ones that attracted me.

I took those widgets with such a long trail and I extended them.
I ported them to Qt4 using QGradients which are faster, and i did some visual improvements: shadows, bumped pointer, configurable colors, angular and linear modes of mouse handling... I added them to the CLAM Widgets plugin and added some configurability so you can change the colors from the designer. And that's how they look now:

Monday, April 9, 2007

PK Widgets integration in CLAM

And last but not least, the other important change i added this Easter to CLAM has been integrating Patrick Kidd's PkWidgets. This was a really dormant to-do. A working implemtation was on the 'draft' cvs from 2004.

On 2004, Patrick amazed the LAD community with his nice looking PKSampler. I must confess that I never got PKSampler sounding because a bunch of missing dependencies on Debian/Ubuntu. But, a part from the audio work, the interface was really gorgeous. Something that was not so common on the Linux Audio scene.

The nice look was mostly due to a clever combination of free technologies: Qt, Python and Povray. Povray rendered 3D widgets with a realistic look, Qt the interface foundation and the resource system and Python to glue it all.
A clever trick allows to load povray images as frames of an interactive animation to render a widget.

At that time I was starting what is now the Prototyper and I was already messing with designer plugins, i could not stand and I ported some of the Patrick widgets to C++ in order to include them in a Designer plugin.

I exchanged some mails with him but the code was left on CLAM draft repository... until Saturday. I updated it to Qt4, added some configuration features, merged some of the new pixmaps and i integrated them on the CLAMWidgets plugin. The result, now you can prototype with CLAM interfaces such that one:

Educational Vowel Synth and ControlSurface Widget

Some months ago I had the idea of doing a Vowel Synthesizer program which could help children to understand why the vowel triangle has some sense and it also could be used to train foreign language vowels.

The core of the idea is that axes correspond mostly to the position of the first two formants F1 and F2. So by a simple mapping, given a point on the triangle you could synthesize any vowel even those in the middle. Also by analyzing incoming voice from a microphone, the system could place a point in the triangle that identifies how far one is from the intended vowel.

I did a first prototype which synthesized something far from human but at least you can identify the vowels when you place the proper frequencies. As i had a proof of concept i stopped there.

This easter i improved the prototype by adding a new control widget: The ControlSurface, which control two parameters by moving a single point. It is really more handy than having two sliders and it is perfect for parameter exploration, not just for the Vowel Synthesizer.

It will also force a change on the way the CLAM Prototyper address the binding of controls as it controls two parameters and our current system binds a widget to a single inlet.

Realtime MFCC and LPC analysis

As I said on the previous blog entry, too much things done in CLAM this Easter. We fully dropped Fltk visualization module from the main libraries. Zach Welch (one of the active new commers) ported Voice2Midi to Qt4 and we moved a subset of the Qt3 visualization module to the SMSTools and dropped the rest. (Zach prepared a set of patches to port it to Qt4 but let's wait until the rewrite). All those drops mean that CLAM size has been reduced to a half of its former size: less mainteinance and faster entry for the new developers.

A few examples stopped being functional because they used Fltk Plots. One of them the LPC_example. It compiled by disabling visualization rendered the example useless. I decided to convert it into a Network Editor example.

After some hacking i had this piece of network working.

After some designer and prototyper hacking i got this interface:

Trying to understand the meaning of the LPC I also added a new output the spectral envelope:

So it captures the spectral envelope which is gonna be very useful for the vowel synth.

Then a user asked for realtime MFCC. As we already had the processings but using portless interface, and LPC visualization could be reused for MFCC, i also took this task. The result:

Mixing it all in a single analysis interface

Vowel formants are even more clear in MelSpectrum that in MelCepstrum or the Spectrum it self. Another idea to be used for the Educational Vowel Synth.

Realtime Voice Gender Change

This Easter has been very productive for the CLAM framework. Holidays and a bunch of new developers that have aproximated the team during these weeks have accelerated a lot the development which had already been accelerated during last months. As consequence, a lot of dormant to-do's has been addressed and most of them deserve a blog entry (pixmap widgets, realtime LPC/MFCC, Qt3/Fltk drop, Qt4 ports, new visualization widgets, new control widgets...). Just take a look at the CLAM-devel mailing list archives or the development screenshots and you'll see a im not exagerating. So let's start from the beginning.

One of the nicer things I worked on and which is going to be the star on CLAM demos for sure, is the voice Gender Change effect on the NetworkEditor. Since Xavier implemented the offline version, it has been arround for a while on the SMSTools turning Elvis voice into Elvira. It was also on the NetworkEditor but crashing or not even sounding.

So, I am a demo whore, let's make people smile. Let's make it realtime. Pau already did some work as he ported almost all the SMS transformation. I just had to fix some of the internal processings, the Pitch shift, and the SpectralShapeShift. Most of the bugs were about detecting non-harmonic parts and figure out which is the best strategy in those cases. In some case this was detected but the action relied on input to output copies implicit on the offline version but not on the realtime one.

What i was not able to solve is the CombFilter. It added a really extrident noise to the residual part. So I disabled it and it does not sound as perfet but... tada! i started listening my sister voice from the speakers instead of mine when i talked the mic, which is specially frightening, most of you know why.

That's the look the network had after having the system completed.

And a first attemp Prototyper interface for an stand alone application:

As soon as it is available as nightly snapshots try it. It is worth to listen. My first experiments i used it to learn how to do a mixt choir in Ardour with just my own voice.

Friday, January 26, 2007

Adding dynamic libraries to a macosx application bundle

CLAM team is now geared toward having again MacOSX binary distribution. We are learning how things in Mac works and it is being a long process. At last it seems that we are getting enough insight. Until now, our Mac packages for CLAM applications depended on the installation of another bundle with clam and third party libraries. Following the advice of Volker Schumacher this would be more handy by having, as we have in windows, all third party libraries within the handle. So we used otool and install_name_tool as the mac developer documentation says. But CLAM has a lot of third party dependencies which are recursive and this was a very hard problem to do it by hand, so Pau and me pair programmed a handy python script which eases the process a lot.

What it does is firstly using otool to retrieve all the dependencies recursively and removes system ones. Then it copies all them to the bundle, changes their id and then changes all cross references among libraries and applications accordantly.

The script is available on the CLAM svn repository. A SCons tool is also work in progress. I will wrote more on int when finished.

Monday, January 22, 2007

BBQed onion springs and Tux evangelism

Last Saturday I could not attend an interesting meeting in Barcelona for the startup of a new organization which has the goal of compensating the increasing privative software lobbing over our autonomous government in Catalonia. I was not able to go because I scheduled for the same day, a typical Catalan BBQ like event, a Calçotada. Anyway I still used that other event to promote Tux cause ;-)

Why? Because my Linux laptop was the jukebox for the event. As result I got some of my friends using Amarok to choose the music they wanted and they liked much the program. Even those that declared themselves completely newbies with computers managed to get some of their music playing. I also activated Beryl which impressed them a lot.

Free CD's to Mario's Pub, chatting about cool linux features... Anything as effective as seeing it running and managing it. When I told them that that was Linux they all said comfortable comments such 'so, it is not as difficult as people says' and 'it's like windows but cooler!'.

Some of my friends asked me to install Kubuntu on his desktop computer. I told one of them to do it yesterday but, sincerely we were too hangover. I must say there were more things in there than Linux evangelism. And pretty funny ones.