If you ever wrote at least 2 audio plugins in your life, for sure you have noticed you had to write a lot of duplicated code. In other words, most of the times, writing a plugin there is very little entropy from your code.

My first approach to this problem was some years ago when i did a simple code generator of the base code of a clam plugin (see these clam-devel threads for more info ‘Commit #11195: templated plugins generator‘ and ‘Frontend for automatic generation of plugin code‘)

Now i’m with a simple but i think powerful project (derived from the needs i noticed at club de audio de la fiuba) to have an application to generate code of different standards using XML based specifications. Then, as before, you nearly only need to write the signal processing code of the plugin (and can forget about the mechanical work).

The idea is to get VST, LADSPA, lv2, CLAM, Audio Units and possibly others standards base code ready to compile for different operating systems and using different build systems. Indeed, once finished, will be easy to implement new modules for others plugins specifications since will consist only into implement an interface.

My proposed xml specification (comments and suggestions are welcome!), showed as a clam plugin definition example is here. Basically contains metadata, input and output ports and controls and other build definitions:

< ?xml version="1.0" encoding="UTF-8"?>
< !DOCTYPE AudioPlugin SYSTEM "AudioPluginDef.dtd">
<audioplugin Version="0.1">
        <metadata>
                <name>TestRtPlugin</name>
                <description>This is a test realtime audio plugin</description>
                <authors>Fulano, Sultano, Mengano</authors>
                <copyright Year="2010">Club de Audio FIUBA</copyright>
                <license>GPL</license>
                <category>Plugins</category>
        </metadata>
 
        <inputs>
                <port Name="L Input">AudioInPort</port>
                <port Name="R Input">AudioInPort</port>
 
                <control Name="Gain" Min="0." Max="1.0" DefaultValue=".5">InControlFloat</control>
        </inputs>
 
        <outputs>
                <port Name="L Output">AudioOutPort</port>
                <port Name="R Output">AudioOutPort</port>
        </outputs>
 
        <outputplugin Standard="CLAM" BuildSystem="Scons" OS="Linux">
                <basetemplatename>Default</basetemplatename>
 
                <clam_defaultconfig> <!--  CLAM plugin specific configuration -->
                        <baseclass>Processing</baseclass>
                        <withconfig>True</withconfig>
                </clam_defaultconfig>
        </outputplugin>
</audioplugin>

I also thought about an UID (Uniqued ID) field at metadata, there is not showed in the example since is not needed to clam plugins.

There is also a .dtd file to check the correctness of the plugin spec.

Share This/Compártelo

Now that I have a decent (though not impressive) publication record, I realize that people might think that it was easy to get here. Not only that, some of you now starting with your first rejections, might think that researchers like me were fortunate enough not to get the kind of reviews you are getting. Even worse, you might think that we are better than you. Here is a secret for you: I have got many more rejections than acceptances during my career. And, although I have managed to improve my stats significantly (experience counts, that's a fact), I still do!

I don't want to generalize here. I am sure there are researchers that manage to get all the papers in, starting on their very first submission, and only rarely get pissed at a rejection. But to be honest, I don't know any of them. Top-tier conferences and journals are designed to have low acceptance rates (10 to 20%). Also, they are supposedly designed not to let "bad stuff" in, but they are not optimized to make sure "good stuff" is not left out!

Here is the best kept secret for researchers: you have to learn to digest your rejections and endure.

A case study

As I was writing my last post on the paper I have published IEEE Transactions on Software Engineering, I was thinking on the long story of this particular submission and thought it might be good to share it. My goal is not to complain about how the publication system works (although there is meat there for several posts), but rather to encourage you to persist and not give up. I have omitted names of journals to preserve anonymity and to avoid pointing the finger.

1. My first move was to send the paper to a 2nd-tier journal. I was working on other journals at that time and this one was not a priority. I simply wanted to get the word out of that part of my thesis. This journal seemed ideal. The result is that, for the only time in my life, I got the paper rejected without revision! Yes, no reviewers or anything like that. Just the editor telling me that the paper was not relevant for the journal. As later events proved, this was pretty much bullshit.
2. Because of the disappointment and the work I had put into it, I decided to send it to another journal. Only that I decided that would be a top 1st tier journal instead. This time, I did get reviews. I have to admit that the reviews were insightful this time. The main issue was that the reviewers wanted me to focus more on the practical case and less on the general model. So I got a Major Revision out of this. I am pretty sure I could have gone for it at that point but decided not to. Again, I had other papers to focus on and this one was not my priority. But I kept the paper and the reviews.
3. The story of the paper would have ended there, if it wasn't because I received an invitation from a researcher I know. He was guess editor to a special edition on the same journal I had sent on (2) and, because he knew my work, was inviting me to submit. Why not? I pulled the draft out of the drawer (figuratively, that is) and started working on the reviews I had previously received in that same journal. Right, isn't it? No, wrong! It turned out that the reviewers were complaining about completely different things. Because this was a special issue, all reviewers were uber-experts in this field. And they questioned technicalities and semantics as if they were very importance. However, the reviews were not bad at all. Actually, the paper might had made it this time to the regular journal. But because it was a special issue and they could only accept 5-6 papers out of 50 submissions, it was rejected... again!
4. So here I am, with a paper I had started working on 5 years before and I knew had not been accepted for bad luck. I took it more or less like it was and sent it to an even better journal (as a matter of fact, out of revenge, I just looked for the journal on software engineering with the highest impact factor). And guess what, it was accepted! I did have to do some revisions though. The funny thing is that those revisions were essentially meant to take the paper to how it was in step one since reviewers asked for less details on the practical case and more meat on the general model.
   

End of the story. So I have had a paper accepted to a top journal like IEEE Transactions on Software Engineering. This paper is essentially the same that I had 5 years ago and was rejected without review by a crappy second-tier one. And in between, I had to steer one way and the other several times... what a ride!

Y. I am convinced! I will send all my drafts tomorrow and hope they eventually make it...

NO!

I don't want the post to be understood as a call to send crappy research anywhere you can in the hope that it makes it at some point. This doesn't work. Period. I review enough papers to know that people send unacceptable stuff (specially to journals). I am talking about papers that are clear reject after you have spent 5 minutes reading them. I feel the pain, and I am the first one that does not want to waste my time reading pseudo-papers that are sent in the hope that nobody notices how bad they are.

Y. You are so right there! People who send unacceptable things for review should be banned from the community, their paper published on a website for everybody to see, and...

Wait, hold on a sec. That is not the way to go either!

Maybe you are reading this post and were fortunate enough to do your PhD in a top US university. And you had an advisor who called you into the office twice a week. An advisor who read each of your drafts 20 times and marked it all in red for you to repeat many times. If you are in this kind of situation, I have some news for you: you are the exception, no the rule. Many PhD students go to just decent universities and are lucky if they have an advisor that is remotely interested in their thesis. Even in that case, it is likely that the advisor has too many things to do to provide any kind of regular feedback.

Students and junior researchers use submissions to get feedback on their research... and to learn. And you know what, I think that, as much as I hate reviewing bad papers, they are right to do so. What do you think?

You're not alone

To finish this post/rant, I wanted to point out that having great ideas rejected is part of human history, you are not alone. Read, for instance, this list where X. Sala i Martin has compiled famous ideas that were rejected (some of them, like the xerox machine, time after time). Also, this post by Michael Nielsen has a very interesting discussion on the reliability of peer review, where he cites other examples of famous scientific ideas that were rejected.

As always, your comments are most welcomed!

"Frameworks generate Domain Specific Languages: a case-study in the Multimedia Domain" is the title of a paper I have authored and has just been published in IEEE Transactions on Software Engineering. As you might have guessed, the title of the paper is a twist on the classical "Patterns Generate Architectures" by Kent Beck and Ralph Johnson.

This publication completes the trilogy of journal articles I intended to get out of my Thesis (two others are "A Domain-Specific Metamodel for Multimedia Processing Systems" in IEEE Transactions on Multimedia, and "A framework for efficient and rapid development of cross-platform audio applications" in ACM Multimedia Systems). My intention was to get this paper published a long time ago but I will save that juicy story for a future post.

But, in any case, what are we presenting in the paper? Before explaining this, you might need to understand, in case you don't already, what a domain-specific language is:

A Domain-Specific Language (DSL) is a high-level programming or modeling language tailored for a specific domain. A DSL lacks the flexibility of general-purpose languages but it offers powerful constructs that are closer to the concerns and constructs of the particular domain.

In this work we claim that the aim of any software development process should be to come up with a DSL. In order to do this we bridge the gap between Model-driven Architectures (MDA), Pattern Languages and Framework Development and embed all into a coherent and agile development model. This is illustrated in the figure below:



Here is the transcript of the abstract (complete preprint pdf here):

(Note: I wrote this as something to tell to the clam-devel mailing list about some of my source-code commits)

About eight months ago, there was a foundation of something like an “audio club” in my university [1]. As soon i learned about that, i quickly got in touch with them and noticed that there was a major interest in analog issues (the only audio area with at least elective, courses in the university). So i told them about all the cool things that are available and ready to do with digital audio, mostly signal processing related. I talked in general, but of course i also talked about clam, with all its prototyping, real-time and easy development of plugins features. Even many of them ended installing and using it, and some even developing with more or less help. One thing to notice is that most of them are students from first years and most (but not all) are students with a basic programming level (because they are from electronics) but strong dsp knowledge (behind this is an university with more emphasis in theory than practice)
We started specifying plugins from a more abstract level (inputs/outputs/controls) and generating the source code base using
CLAM’s Templated Plugins Code Generator [2] and prototyping some simple applications. But one of the things we ended up doing was to take advantage of clam as platform to prototype medic related applications like filter ECG signal from noise in realtime, and some like _vice-versa_, i mean applying some processing knowledge from that area to audio.

Some of that work (one hour per week average) it’s now in the repo, most remarkable i think are filters work, by above the adaptative notch one (which even was used as a demo of a talk of one of the members about the steepest descent algorithm and its application to filter ECG signals)

Some development screenshots:
http://clam-project.org/wiki/Image:FilterByCoefExample.jpg
http://clam-project.org/wiki/Image:FilterExample-LP-HP.jpg
http://clam-project.org/wiki/Image:ThreeBandFilterOutputWithWhiteNoiseAsInput.jpg
http://clam-project.org/wiki/Image:GaussianWhiteNoiseHistogram.jpg
http://clam-project.org/wiki/Image:UniformWhiteNoiseHistogram.jpg

[0] FIUBA: Engineering Faculty of Buenos Aires University
[1] Group: http://code.google.com/p/club-audio-fiuba
Source code repo: http://groups.google.com/group/club_de_audio_fiuba
[2] http://audiores.uint8.com.ar/blog/2009/08/17/showing-a-little-about-clam-as-a-prototyping-tool-at-the-audio-club-of-fiuba/

Share This/Compártelo

The CLAM project is pleased to announce the first stable release of Chordata, which is released in parallel to the 1.4.0 release of the CLAM framework.

Chordata is a simple but powerful application that analyses the chords of any music file in your computer. You can use it to travel back and forward the song while watching insightful visualizations of the tonal features of the song. Key bindings and mouse interactions for song navigation are designed thinking in a musician with an instrument at hands.

Chordata in live: http://www.youtube.com/watch?v=xVmkIznjUPE
The tutorial: http://clam-project.org/wiki/Chordata_tutorial
Downloat it at http://clam-project.org

This application was developed by Pawel Bartkiewicz as his GSoC 2008 project, by using existing CLAM technologies under a more suited interface which is now Chordata. Please, enjoy it.

The CLAM project is delighted to announce the long awaited 1.4.0 release of CLAM, the C++ framework for audio and music, code name 3D molluscs in the space.

In summary, this long term release includes a lot of new spacialization modules for 3D audio; MIDI, OSC and guitar effects modules; architectural enhancements such as typed controls; nice usability features for the NetworkEditor interface; convenience tools and scripts to make CLAM experience better; enhanced building of LADSPA plugins and new support for LV2 and VST plugin building; a new easy to use application to explore songs chords called Chordata; many optimizations, bug fixing and code clean ups.

Many thanks to the people who contributed to this release, including but not limited to the GSoC 2008 students and all the crew at Barcelona Media’s Audio Group.

Some details follow:

• Chordata is a new CLAM application which offers a user friendly way to explore the chords of your favourite songs, using already existing technology in the CLAM framework but with a much simpler interface. Video
• The spacialization module and helper tools, contributed by Barcelona Media audio group, turn CLAM in tandem with Blender and Ardour, into a powerful 3D audio authoring and exhibition platform. Here you can see some related Videos.
• Typed controls extend CLAM with the ability to use whichever C++ type as the message for a control. So, not just floats, but also bools, enums, integers, or envelopes can be sent as asynchronous controls. Examples on boolean and MIDI controls are provided.
• NetworkEditor has been ported to the QGraphicsView framework. Dealing with heavy networks such the big ones used in Barcelona Media have pushed many usability enhancements into its interface: multi-wire dragging, wire highlighting, default port and control actions, network and in-canvas documentation… Video
• It also made necessary to provide a tool such clamrefactor.py to perform batch high level changes to clam network XML files such as renaming processing types, ports, or configuration parameters, changing configuration values, duplicating sets of processings, connecting them…
• Music Annotator application now is designed to aggregate several sources of descriptors and update them after edit. Descriptors are mapped to a work description schema that can be graphically defined. Also semantic web descriptor sources to access webservices such as MusicBrainz have been implemented.

You can download them from the download page. Source, windows, debian and ubuntu packages are available. Contributed binaries for other platforms are welcome.

See also: development screenshots, the CHANGELOG, the version migration guide and the new CLAM group on youtube.

A couple of weeks ago, I attended a three-day course on Hadoop from the guys at Cloudera. Although I had heard and read about Hadoop before, this was a great opportunity to learn many details on Hadoop and find out about several tools that make up the Hadoop ecosystem. If, like me before, you only have a rough idea of what's in Hadoop, you should be interested in the post. Take what I say with a grain of salt, since I am no expert in Hadoop. However, because I am not an expert, I think I can guarantee a fresher look and you can trust I am not trying to sell you the project. But, if you are an expert and you read the post, you might want to give feedback in case I got something wrong.

Hadoop is an open source java implementation of the MapReduce framework introduced by Google. The main developer and contributor to Hadoop, however, is Yahoo. It might seem weird that one of Google's main competitors releases an open source version of a framework they introduced. More so, when Google has recently been granted a patent for it. However, it seems unlikely that Google can execute their patent. One of the main reasons is that Map and Reduce functions have been known and used in functional programming for many years. Another reason is that Hadoop has gained a huge popularity as part of the Apache project. Enforcing the patent would not get Google much love from many companies that are now making a living of it or using it as an important component in their web architecture.

But, before we go into any more detail, it would be good to understand what can Hadoop be used for and when we should think about adopting it. First, and above all, Hadoop is a framework for data analysis and processing. Therefore, if you have no data, or if you have no need to process it, do not continue with this post. Hadoop is sometimes presented as an alternative to traditional relational databases. However, it is not a database (although it does provide a noSQL one called HBase as one of its tools), it is a framework for distributing data processes. Ok, so here was the second keyword: distribution. If you think you can do whatever you need to do in a single machine, you don't need Hadoop. However, you might want to look at it anyway, since distributing your data processes can be cheaper and also much more reliable. And finally, and related to the previous, using Hadoop only makes sense if you are processing large datasets and by large I mean several TB's.

However, even if your problem fits into the three previous conditions (distributed processing of large datasets) you can still not be completely sure Hadoop is your solution. Distributed relational databases are still an option. I won't go into the details, but you might want to read at some voices that are recently stepping in to defend the scalability of relational databases and their applicability in highly demanding large datasets. These two posts are good reading: "Getting Real about NoSQL and the SQL-Isn't-Scalable Lie" and "SCALE 8x: Relational vs. non-relational". I would also recommend this recent presentation on "What every developer should know about database scalability"

So now that we have some intuition of when Hadoop may be of interest, let me introduce the two main issues behind Hadoop: MapReduce and HDFS.

MapReduce is a programming model introduced by Google, which is at the core of Hadoop. It is based on the use of two functions taken from functional programming: Map and Reduce. Map processes a (key,value) pair into a list of intermediate (key,value) pairs. Reduce takes an intermediate key and the set of values for that key. Both the mapper and reducer functions are written by the user. The framework groups together intermediate values associated with the same key in order to pass them to the corresponding Reduce.

MapReduce claims to be a sufficiently generic programming model that most data processing tasks can be decomposed in such a way. If you are interested in learning more, I recommend you start with Google's paper. You can also take a look at Google's set of videos introducing the framework. If you want a more "academic" presentation, you might want to take a look at these UC Berkeley classes.

The other important core issue in Hadoop I mentioned before is the Hadoop Distributed File System (HDFS). HDFS is the equivalent of the Google File System (GFS) used in the original MapReduce framework. This filesystem is optimized for reading in streaming large files (from several gigabytes to terabytes). Note that HDFS does not allow, for instance, to edit a file once it has been written.

Ok, so now we have the basics in place: how do we use Hadoop? Since Hadoop is written in Java, the most straightforward to get started is by using its Java API. If you look at the Hadoop Map/Reduce tutorial, for instance, you will see how the framework is introduced through its Java API.

But, if you want to use Hadoop but would rather keep away from Java, there are plenty of other options. First, there is Hadoop Streaming, which allows to use arbitrary program code with Hadoop. Stdin and Stdout are used for data flow, and each mapper and reducer is defined in a separate program. This comes in very handy if you want to use Hadoop through a scripting language. Now, if you want to have a greater performance in your mapper and reducer functions and would like to call compiled C++ code instead, your solution is called Hadoop Pipes.
Now, what if you still would like to access the Hadoop framework but do not fancy the MapReduce programming mode? In other words, is there any higher-level and more programmer friendly way to interface with Hadoop? And the answer is, of course, yes. There are several ways to do this but I will mention two of them: Hive and Pig. Hive is a tool developed at Facebook that allows for an SQL-like access to the Hadoop infrastructure. Although the project is not very mature yet, this is a very interesting option to consider and it seems to be giving very good results to Facebook. The other option is to use Pig, developed by Yahoo. Pig provides a higher-level language called Pig Latin that increases productivity, especially if you are dealing with non-java programmers that are closer to the domain (e.g. data analysts). Pig Latin is a dataflow language and it even has a graphical front-end plugin for Eclipse called PigPen.

I would not like to finish this personal overview of the Hadoop Ecosystem without mentioning
Mahout, a project for distributed machine learning with Hadoop. Among its examples, Mahout includes an implementation of several collaborative filtering algorithms for recommendation. I would also encourage you to take a look at this list of academic papers about or using Hadoop.

At this point I have to say that I have mixed feelings about Hadoop and about MapReduce itself. Although it is a powerful framework with immediate application to real-life problems that involve very large datasets, the model feels more like a kludge than a paradigm shift. I understand why people turn to tools like Hive and Pig that hide the MapReduce complexity behind more friendly models such as ER and Dataflow networks. Providing a framework that is both efficient, usable but also conceptually illuminating is definitely an area to work in the future. And it seems that I am not the only one thinking along these lines. Even Yahoo themselves are looking into new ways that go beyond Hadoop and MapReduce.

Some days ago I was surprised to find (the cult of) Scrum in a list of the Worst Technologies of the Decade. I posted the link on LinkedIn's Agile Alliance group and that started a mild discussion where most people more or less defended Scrum. What follows is my personal take on the issue: Is Scrum really (that) evil?

(No need to say that if you know nothing about Scrum you should at least learn something about it before proceeding with the rest of the post)




Ok, so the first thing people will tell you about Scrum is that it is not a method, obviously not a technology, not a methodology... then what is it? Scrum sells itself as a ... (drums here) "framework"! For those of you with a less agile background, another well known example of a framework in the context of development methods is the Rational Unified Process. If you are thinking on proposing a new development "method", you should definitely think about selling it as a framework. This will bring you a number of benefits, the most important being:

1. You can say that your framework is useful for any kind of situation
2. If anything goes wrong, you can always blame whoever instantiated the framework for not doing it right

Well, that is exactly what happens with Scrum. You can not say it is evil in itself, not even good or bad: it will be as good or bad as its particular instance. This is, of course, unfair with Scrum users that may have the feeling that if anything goes right it will be thanks to the framework, but if anything is wrong it will be their fault.

(UPDATE: The following paragraph has been edited after feedback from comments to the post and Kent Beck himself. I only had time to skip through the 2nd Edition of XP Explained, but I think I got the point.)

Unfortunately, the alternative is not very appealing either. Other methods like eXtreme Programming in their first incarnations would tell you that the only way to apply the method was to apply all practices. There was an important point in the message since some practices are actually complementary and feedback into others. So you can't, for instance, decide to skip Continuous Integration and still think you can get away with it. In any case, reality is that you cannot expect all teams to apply all practices and while practices like Unit Testing reach 60% usage, others like Pair Programming do not even reach 25%. Also as Kent Beck acknowledges in the preface to the 2nd edition of his foundational eXtreme Programming Explained, enforcing all practices is like enforcing a given programming style. And that might not be fit in every situation. The current proposed solution in XP is to present some primary practices and some corollary. Also now the message is that practices cannot be enforced and need to be evaluated in each situation. This brings XP closer to being a toolkit of practices, which is not far from the concept of framework: the responsibility is on the particular instance or application.

Maybe the ideal solution would look something like: propose a generic framework that includes several practices and variations and then illustrate the framework with several practical instances that can be used depending on the project at hand. Of course, I am no the first one to think about something like this. As a matter of fact, Alistair Cockburn's Crystal methodologies were designed precisely with this idea in mind. Unfortunately the author did not get very far in proposing the different instances and now the only one fully developer is Crystal Clear, valid for smaller and lighter projects.

In any case, Scrum is a framework and when something goes wrong it is pretty likely that the "user" will be to blame. However, as I have just explained, there is no clear alternative to putting so much weigh on the particular instance of a method.

Still, can we say that there some things that are inherently good or bad about scrum?

The good things

Of course there are a few things that are good about Scrum regardless of how you apply the framework. To name a few:

• Accountability: Scrum makes it much easier to make teams accountable for what they do. It also makes it easier to hold clients accountable for what they asked and even managers for what they did not provide. Forget about eXtreme Programming cards and boards, scrum artifacts like the burndown charts or the impediments or product backlog are great tools if what you need is more accountability in your life... I mean projects.
  
• Credibility of Agile: Let's face it, the first thing that comes to mind to many people when they read the agile manifesto is a bunch of long-bearded hipster coding with one hand and eating chips with the other. And this impression might not improve much more when you mention things like the "planning game" or.... (my god!) Pair Programming. Scrum brings credibility to Agile because it looks like "serious stuff".
  
• The agile for non-developers and managers: Believe it or not, those who have to decide whether to promote Agile in a company may have no clue of what the life of a developer is like (and many could not care less). If you plan selling Agile by saying you will make developer's life easier, think again. But if you talk about shortening cycles, minimizing risk and... improving accountability (that is offering tools for managers to understand what is going on) you might have a chance. The biggest strength of Scrum is that it makes it much easier for managers and decision makers to buy into Agile. And believe me, this is a major issue that by itself may justify Scrum.
  

The bad ones

• Too many artifacts: Ok, but wasn't one of the goals of becoming agile to offer a lightweight method with as few artifacts as possible. Then, what are all these artifacts doing in my life now? Product backlog, sprint backlog, impediments backlog, product burndown chart, sprint burndown chart, daily meeting, retrospective, sprint planning... is this really necessary? The truth is that if managed right many of these artifacts are not a huge overhead and are useful, really. And again, they are needed to convince managers that we are doing things right. The problem is that, if we are not very careful, it is very easy to abuse them and end up making them more important than the product or team itself.
  
• Too much focus on the process: Related to the previous, it is easy to fall into a situation where the process is more important than anything else. It is not about your project, your product, and your team... it is about getting the process right. What? This sounds more like CMM than Agile!
  
• Developers? What developers?: And finally... where does that leave developers? If you implement Scrum and nothing else, you are pretty likely to turn developers' lifes into a sweatshop 2.0: they have to work more, faster, and better.... and are more accountable than before. Scrum does not care much about developers, so you better do this yourself. That is why a preferred approach is to sparkle in some XP practices on top of a Scrum-driven project organization. However, because XP will not be so popular among managers and decision makers you are likely to have much less support (if you don't agree with this, just try mentioning pair programming). Scrum by itself is not developer-friendly and that is a fact.

Conclusions: is this really agile?

So now do me a favor and take a moment to (re)-read the Agile Manifesto. What do you read in the first line? "(We value) Individuals and interactions over processes and tools". The main sin is that it makes it really easy to revert the sign in the equation. It is much easier to sell processes and tools to managers and because Scrum is a framework it is very easy to in a way that is not even agile anymore. of Scrum

My advice, however is not to avoid Scrum. Use Scrum to convince your organization of the benefits of Agile. Use the "processes and tools" view to make your point to managers and decision makers. But,

• Do not forget to build motivated teams
• Value developers and educate them in eXtreme Programming techniques
• Make them feel that they are far more important than any Scrum process or tool by allowing self-organization
• Make sure that Scrum Masters (or project managers and the like) understand they dual role of using the "process" to improve accountability and upwards reporting while using people's skill and valuing the individuals in the team.

Of course, this is not the magic bullet of agile implementation. As a matter of fact, the combination of Scrum with eXtreme Programming techniques is already a favored approach in many companies (according to the 2009 State of Agile study 24% of the companies use this hybrid). But again, individuals and interactions may be more valuable than any process or tool. So at the end, it may not be so much about how you combine or instantiate your particular flavor of agile method but about how good and motivated are your teams.

As always, would love to hear your comments and experiences.

Let me post about some of the latest changes on the CLAM build system.

The CLAM project has been distributing two kinds of shared libraries: the main library modules (core, audioio and processing) and a set of plugins which are optional (spacialization, osc, guitareffects...). Plugins are very convenient since programs like the NetworkEditor can be extended without recompile and enable third party extensions. They are so convenient that we were seriously considering splitting processing and auidioio as plugins.

But the use of content of a clam plugin is limited to abstract Processing interface. No other symbols are visible from other components. That has a serious impact on the flexibility to define plugin boundaries. For example, if a plugin defines a new data token type, any processings managing that token type should be in that same plugin. To use symbols of one plugin from another implies installing headers, provide soname, linker name and so on. That is, building a module library.

So, if plugins want to be libraries and libraries want to be plugins, let them all be both. Each module will be compiled as library (libclam_mymodule.so.X.Y.Z), with soname (libclam_mymodule.so.X.Y), linker link (libclam_mymodule.so), headers (include/CLAM/mymodule/*), pc file... and it will also provide a plugin library (libclam_mymodule_plugin.so) which has no symbol by itself but is linked against the module library. When a program loads such a plugin, all the processings in the module library become available via the abstract interface. On the other side, if program or a module needs to use explicitly the symbols of another module, it just has to include the headers and link against the module library.

I just applied the changes to the plugins and seems to work nicely. Adapting the main modules will be harder because the old sconstruct file, but it is a matter of days and we can split them. I moved a lot of common SCons code to the clam.py scons tool. There is a cute environment method called ClamModule which generates a clam module including the module library, soname, linker name, plugin, pkg-config, and install targets. I also added some build system freebies for the modules and applications:

• All the intermediate generated code apart in a 'generated' directory
  
• Non verbose command line
  
• Colour command line
  
• Enhanced scanning methods with black lists

Well, do not rely too much on the current clam scons tool API. Changes are still flowing through the subversion. Of course, warn me if I broke something. ;-)

After a long refactoring to get typed controls into clam without breaking anything, we already have them. Kudos for this achievement go also to Francisco (who started the whole thing as its GSoC project), Hernan, Nael and Pau.

Now controls are defined just like ports with a type. So for example, you can define an out control being the type OutControl<MyType>. As a side effect, control callbacks came in natural way. Instead of using a different class (formerly InControlCallback<MyType, HostProcessingType>), now you just have to pass a processing method to the control constructor. Templates do the magic too, but that is hidden from the processing programmer API which is cool. See, some example bellow.

So, once we enabled typed controls working, now is time to have more than just float controls. The main problem now is that in order to get some useful new control type you have to modify the network editor and the prototyper to make them useful.

Although the most demanding needs are for enum and integer controls, I started with simpler bool controls. My goal is you don't have to modify the NetworkEditor or the Prototyper to introduce a new control type. That is, a plugin could add new control senders, control displays, default connected processings (double clicking on a control) and binders for the prototyper (to locate ui elements to link to processing controls). So i wanted a new simple use case not being float to explore a feasible API.

Below you can see a network with a BoolControlSender (widget hxx/cxx, processing hxx,cxx) and a BinaryCounter (hxx,cxx) outputing into two BoolControlDisplay (widget hxx/cxx, processing hxx,cxx). Maybe is a little late for using CLAM for your Christmas lights, i guess ;-)



Currently, instead of bools we use floats considering a threshold for being true or false. A new ControlGate processing provides a transition by doing such translation:

So now is time to look to the code I had to add and see what can be enhanced to ease adding new control types:

• One of the things I didn't liked during the implementation is having to add an entry into a long list of 'if' statements in ProcessingBoxEmbededWidget.cxx. This is clamming for a refactoring into a Factory.
• Also the menu entry filling (to connect to new processing) and the default create-and-connect action become a list of if clauses with the type as parameter.
• Both, prototyper binders and embedded widgets had to duplicate the control sending code. That could be generalized into a binder object that both use.

So, it is clear that there is room for a lot of enhancement and it looks like those enhancements could also be applied to ports as well :-)

Clam developers Pau Arumí and Natanel Olaiz recently presented some new work in the fantastic Blender conference in Amsterdam. The talk was about a technology developed at BarcelonaMedia involving an innovative usage of Blender for 3D audio using CLAM for the audible-scene rendering and decoding and Ardour for playing out to any loudspeaker-layout. It was really nice to meet Blender developers and artists, and the overall conference was fun and a great experience! Now we expect to collaborate more with the Blender project in the future.

Our talk was entitled: Remixing of movie soundtracks into immersive 3D audio

The summary:
We present a use of Blender for an innovative purpose: the remastering of traditional movie soundtracks into highly-immersive 3D audio soundtracks. To that end we developed a complete workflow making use of Blender with Python extensions, Ardour (the Digital Audio Workstation) and audio plugins for 3D  spatialization and room acoustics simulation. The workflow consists in two main stages: the authoring of a simplified scene and the audio rendering. The first stage is done within Blender: taking advantage of the video sequence editor playing next to a 3D view, the operator recreates the animation of sound sources mimicking the original video. He then associates the objects in the scene with existing audio tracks of an Ardour session with the soundtrack mix and, optionally, adds acoustics properties to the scene prop materials (e.g. defining how a wooden room will sound) to render acoustics simulation using ray-tracing algorithms. In the second stage, a specification of the loudspeakers positions used in the exhibition is given, and the Ardour session with the soundtrack is automatically modified incorporating all the Blender’s edited sound scene, the necessary routing, and the 3D audio decoding plugins such as Ambisonics and other techniques implemented with CLAM.

The slides are available (we hope to add the accompanying videos soon).

Last week, at the recent ‘audio club’ of my university, I was showing how to work with the CLAM framework as a tool to prototype realtime audio signal processing applications in a simple and fast way.

We started with an example network to show some about the NetworkEditor capabilities: karaoke.clamnetwork

After that, we continue with a simple ‘diodo distortion’ plugin:

We specified and generated the source code base in this way:

We wrote this code:

bool Do()
        {
            bool result = Do( mEntrada.GetAudio(), mSalida.GetAudio() );
 
            mEntrada.Consume();
            mSalida.Produce();
 
            return result;
        }
   
        bool Do(const Audio& in, Audio& out)
        {
            int size = in.GetSize();
 
            const DataArray& inb = in.GetBuffer();
            DataArray& outb = out.GetBuffer();
 
            for (int i=0;i<size ;i++)
            {
                if ( fabs(inb[i])>0.8 )
                    outb[i] = inb[i]&lt;0.? -0.8:0.8;
                else
                    outb[i] = inb[i];
            }
            return true;
        }
</size>

And built this net to try it:

The source code of the plugin ready to be compiled is here: pluginDistorsiónDiodo_ClubAudioFiuba.tar.gz

As extra, I leave here pluginDistorsiónDiodoConControlDeClipping_ClubAudioFiuba.tar.gz the same diode distortion, but with a clipping control to set the threshold when playing.

They liked these kind of prototyping features a lot, so probably we’re going to keep using it at the club.

Share This/Compártelo

GSoC 2008 is already here! We are preparing our submision for CLAM as organization and I hope we are as lucky as last year. For GSoC 2007 we got 6 fervent students who pushed CLAM a big step forward. We still don't know whether we will be selected as organization or not. We haven't even filled the submision data. But it is time to trigger some resorts. So, what to do now?

If you are an experienced CLAM developer, please consider becoming a mentor. The more mentors the more students we can cope with.

If you are a user, is the time to push your favourite feature into the GSoC project proposals.

If you are an student wanting to be part of the program, I advice you to get involved with the project from now as we will consider early involvement a big plus for eligibility.

If you are Xavi, Pau or myself, then you should fill CLAM submision instead of blogging ;-)

I love summer.

I recently did an spike on what we need to make VST plugins first class CLAM citizens. CLAM allows to visually build JACK and PortAudio based applications with Qt interfaces as well as GUI-less VST and LADSPA plugins. The more flashy feature of VST is user interfaces that are mostly built using VSTGUI. We are using Qt as interface for JACK and Portaudio based apps because we are using the nice features of Qt toolkit to dynamically bind the UI elements and the underlaying processing. Moreover, Qt styling features enables shinning designer-made interfaces. Why not being able to reuse the same interface for VST and JACK? That has been a long standing TODO in CLAM so now is time to address it.

In summary, we fully solved croscompiling vst's from linux and we even started using qt interfaces as vst gui. In that last point, there still is a lot of work to do, but the basic question on whether you can use qt to edit a vst plugin is now out of any doubt.

To make the spike simpler, and in order not to collide with other CLAM developers, currently working on it, i just left apart all the CLAM wrapping part, just addressing vst crosscompiling and Qt with the sdk examples.

Cross compilation was pretty easy. This time I found lot more documentation on mingw and even scons. Just by adding the crossmingw scons tool we are already using for the apps and i managed to get Linux cross-compiled plugins running on Wine.

Adding a regular vstgui user interface is just a matter of compiling vstgui sources along with the example editor that comes in the sdk.

Once there, we should address Qt. VSTGUI is just a full graphical toolkit implementing the 'editor interface' plus a toolkit with some provided widgets and, i guess, a way of automating the binding of controls to processing. So what we need for qt is to implement the AEffEditor interface using the qt toolkit instead. The first problem is about the graphical loop. You have to create a QApplication and calling qApp::processEvents() on the editor's idle method so that qt widgets get responsive. The problem then is that, if you don't provide a QWidget as parent to your interface, it becomes a top level window ignoring the host provided window that still appears as an empty one.

VST host provides such window as a native Windows handle. How do you create a widget on an existing window handle? Months ago trolls redirected me to a commercial solution. Not such a 'solution' for us, a FLOSS project. So i was digging in windows qt source code for a hack when i found the answer just at the public and multiplatform QWidget api. QWidget::create works like a charm. The following simple class is a native window wrapper you can use as a regular QWidget.

class QVstWindow : public QWidget
{
        Q_OBJECT
public:
        QVstWindow(WId handle) {create(handle);}
        QVstWindow::~QVstWindow() {}
};

Still there are some issues: focus handling, reopening, drag&drop... But the basic mouse clicking and resizing works

Once i got that, loading a designer ui file was very easy.

As I said there are still many caveats to solve. A matter of playing with it and refining things. Here is a list of TODO's:

• Communicate controls from and to the interface
• Handle focus and other events properly
• Build a CLAM network wrapper which reensembles more the one for LADSPA
• Wiki documentation on how to build your own plugin
• One button plugin generator like the one we have for LADSPA ;-)

I feel that there is more people around other projects interested in using Qt for VST plugins so this is also a call for collaborative research on pending issues, at least the generic ones. Contact us on the CLAM development list or for a broader audience in the Linux Audio Developers list.

Several nice CLAM related presentations has been given in conferences during last month. At the Linux Audio Conference in Parma, we presented an article on Blender-CLAM integration for real-time 3D audio (paper, slides, and video available at the link) and we also gave a workshop on CLAM app and plugin prototyping features. At the WWW2009 in Madrid, we presented an article on the new web services based extractors for Annotator and the data source aggreation interface also some videos of the presentation and demos are available featuring data sources aggregation and live chord extraction from youtube videos.

I was in Wired magazine last week:

http://www.wired.com/gadgets/mods/multimedia/2009/03/gallery_instruments?slide=22&slideView=3

Leyendo el diario:

EE.UU. dice que veinte países darán más contribución civil o militar en Afganistán
Gates asegura que varios aliados de la OTAN le han asegurado que “están dispuesto a incrementar su contribución militar, civil o de entrenamiento”

Eh????

Cracovia (Polonia). (EFE).- El secretario de Defensa estadounidense, Robert Gates, aseguró…

Ahhh!

Para aquellos interesados, e intentando contribuir al indexado de los buscadores… El sitio de CLAM se ha mudado a http://clam-project.org

Video
-- To view it on Youtube, click HERE (You may choose the HD mode to view a high quality version)
-- To download this video, click HERE

Screenshots

Project-1: Web-based extractor

  

 

Project-2: Clam Aggregator

--Setting the Configuration

--Editting the Multi-level Descriptors

 

 

--Viewing the Combined Schema

Video
-- To view it on Youtube, click HERE (You may choose the HD mode to view a high quality version)
-- To download this video, click HERE

Screenshots

Project-1: Web-based extractor

  

 

Project-2: Clam Aggregator

--Setting the Configuration

--Editting the Multi-level Descriptors

 

 

--Viewing the Combined Schema