A Look at George Tzanetakis’ Innovations in Music Classification

A great article about George Tzanetakis‘ 10 year work on MIR and software development:  A Look at George Tzanetakis’ Innovations in Music Classification.

I feel really lucky (and proud) to know George since the early days of Marsyas (around 2003) and then to actually meet him in person here in Portugal some time later.

I ended up doing 3 research interships under his supervision at the University of Victoria, BC, Canada, during my PhD, and we currently keep a close collaboration in the scope of Marsyas and a R&D project on the topic of CASA (Computational Auditory Scene Analysis).

Congratulations George! And keep up with the good work! 🙂

Marsyas and Open Frameworks

I’ve been trying, together with André Perrotta, to make Marsyas and Open Frameworks (OF) play nicely with each other. The idea is to be able to use Marsyas inside an OF project.

Usually this is done using an OF addon, and Marsyas already provides an experimental ofMarsyas addon in the SVN repository (check it out at here, and some OF examples that use Marsyas here – these locations in the SVN repo may change place in a near future, though, as we probably tidy up the directory structure soon).

However, some problems seem to exist in making Marsyas  and OF play nicely together:

1. you’ll find that there is a clash between the MACRO define PI in OF and the const variable with the same name (elegantly) defined in the Marsyas namespace (MACROS could not care less about namespaces, and thats one of the reasons why its use should be sparse… and careful). Options to solve this would be to rename PI in Marsyas or in OF to some distinct names. This would imply having to modify all occurrences of PI  in one of the libs, essentially creating a fork of the code. A better solution (suggested by Pedro Silva in the Marsyas developers mailing list, is to just do #undef PI after the includes form OF, and just before the includes of Marsyas in your main code).
2. OF must be built as a 32 bit lib (at least in OSX 10.6.7) because of some legacy issues with QuickTime. Marsyas is built by default as a 64bit lib, so when you try to mix them together, the refuse to link. So, be sure to compile Marsyas as a static 32bit library (i.e. libmarsyas.a) before including it in an OF project. The way to do so in CMake is to set the CMAKE_OSX_ARCHITECTURES to i386 . Then in the OF Xcode project, you just have to point it to the correct 32bit libmarsyas.a lib, and make sure it also knowns about the corresponding .h headers. In case you wonder how to know if a library is 32 or 64 bit in OSX, have a look here.
3. As far as it was possible to understand, the ofMarsyas addon still has some problems (there are some hardcoded paths in some of the #include calls, and ofxThreads still borks in some occasions), and we are in the process of investigating it and will post about our findings ASAP.

We’ll post some additional info (and hopefully more detailed info) soon.

GPL Enforcement in Apple’s App Store/Android Market Place

So it seems that using GPL licensed software for iOS apps distributed on the Apple App Store (and yes, there are “other ways” to distribute software for the iOS-ish platform ;-)) is a problem…

According to Columbia Law School professor Eben Moglen and head of the Software Freedom Law Center (SFLC),

“The problem isn’t in the license terms. The problem is that the Apple App Store ToS for people wanting to distribute through it require that each app sold (even at price zero) must be licensed for use on a single device only. Permissively-licensed FOSS can be transacted for in the App Store, because its license can be replaced by single- device-only terms. Copylefted software can’t be un-freely relicensed, so it can’t be transacted for there under Apple’s current ToS.”

The Free Software Foundation confirms this situation, as can be understood from this post on their website about GNU Go on iOS :

GPL Enforcement in Apple’s App Store — Free Software Foundation — working together for free software.

“An iPhone port of GNU Go is currently being distributed through Apple’s App Store. However, this distribution is not in compliance with the GNU GPL. The primary problem is that Apple imposes numerous legal restrictions on use and distribution of GNU Go through the iTunes Store Terms of Service, which is forbidden by section 6 of GPLv2. So today we have written to Apple and asked them to come into compliance. We would be happy to see Apple distribute these programs under the GPL’s terms, but unfortunately, it seems much more likely that they’ll simply make the problem go away by removing GNU Go from the App Store.“

An interesting question is: “What about Android?”

Android vs. iPhone: The GPL Question

According to Moglen, if you want to distribute your GPL-software on Android, you should be in the clear:

“So far as we know–and we have reviewed the Google Android market terms recently, so change would have to have occurred within the last few weeks–they do not place any limitation on how a market participant’s application is licensed that would inhibit distributing Android applications in the market under copyleft licensing.”

So, according to various specialists, the Android Market provides some flexibility of its terms in what regards app distribution, which when carefully tuned, allows compliance with the GPL (contrary to Apple App Store, which has zero flexibility on their ToS).

An interesting point to note regards Dual Licensed GPL software (as is the case of Marsyas). In such cases, a developer may acquire a commercial license of the software (freeing it from the GPL license terms) and therefore use it for commercial use (without being obliged to distribute any source code) or develop an iOS app and distribute it on the Apple App Store (even as a free app).

Marsyas Developer Blog

George just started a brand new Marsyas Developer Blog.

Great way to keep up with the latest and greatest in Marsyas development! 🙂

Marsyas for MIR at School of Arts, Catholic University, Porto, Portugal

Today, George Tzanetakis is giving the last couple of lectures on MIR at the Catholic University here in Porto. Students will learn about MARSYAS.

[Blatantly copied from Fabien’s blog ;-)]

OSX: Getting Cmake to use a custom python framework

So I’m using a different python install from the one provided OEM in OSX by Apple. Specifically, I’m using Fink to get a more recent version of python 2.5 (but it could be MacPorts – the following problem would be the same).

Having python and swig installed in my osx box (both from Fink), I’m now trying to build the Marsyas library with python bindings, by means of swig, so that it becomes a python module I can use when coding in… er… python ;-).

The problem is that Cmake, when looking for the python installs and dependencies in my OSX box  (which it does when I activated the WITH_SWIG flag in Marsyas CMake build configuration), only looks for the python install provided by Apple in OSX (which is in fact a “framework” (in Apple sense) and not a library) and doesn’t know a thing about the Fink installed python (which lives in /sw/bin).

The result (and problem) is that if I start python (from Fink) and do “import marsyas”, it returns an error because that module was not in fact installed for it (it was installed for the Apple OEM python install, which I don’t want to use).

I found this blog where someone had a similar problem using Opencv ad Python and kind of fixed it, but I don’t find the proposed solution elegant and I’m still looking for less hacky fix to this issue.

Any suggestions?

OSX: Python and friends (from Fink)

So I finally found the time (and need!) to properly install Python in my OSX10.5.6 box, together with some nice modules I’ll need for some of my current research/development work. I’ve followed a quite instructional site (see it here and here) on how to do it, but for Marsyas you’ll only need the following modules:

• python2.5 (from Fink, and not the one provided by Apple in OSX, which is a kind of old and hard to manage version of python)
• iPython2.5
• scipy-py25
• scipy-core-py25 (aka NumPy)
• matplotlib-py25

After you install all the modules (go grab a coffee because they will take a substantial amount of time to build!),  you still need to make sure you call the Fink’s installed python and not the OSX OEM python install (you can ask OSX which python is currently being used in the terminal with “$ which python”). Fink installs python at /sw/bin/python2.5, so in order call it from anywhere you should update you .bash_profile with:

export PATH=/sw/bin:$PATH

This way, you can call python2.5 from anywhere (the same applies to any other Fink installed tool). If you want to drop the 2.5 part, just create a symbolic link to python2.5 in /sw/bin, like this:

$ cd /sw/bin

$ ln -s python2.5 python

And that’s it!

I’ll now move on to play with Marsyas and SWIG (which gets installed for you by Fink when installing the modules above) and probably report back here in case I find any troubles/tips.