Archive for July, 2006

Posted on July 31, 2006 - by jono

Jokosher in Edgy

Nice:

jono@edgy:~$ sudo apt-get install jokosher
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following extra packages will be installed:
  gstreamer0.10-gnonlin python-alsaaudio python2.4-alsaaudio
The following NEW packages will be installed
  gstreamer0.10-gnonlin jokosher python-alsaaudio python2.4-alsaaudio
0 upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
Need to get 690kB of archives.
After unpacking 2003kB of additional disk space will be used.
Do you want to continue [Y/n]? y

Thanks to Daniel Holbach you can now grab Jokosher from EdgyÅ› archive.

Posted on July 30, 2006 - by jono

MythTV on Dapper: Advice Required

As regular readers may well remember, I installed a MythTV quite some time ago. I got it up and running on Ubuntu Breezy, with video out from my ATI card and support for my remote control and LCD panel. Feeling rather smug about building said box, I showed it off to all and sundry to which the responses sounded like an episode of Batman. Since then, the box has recorded hundreds of gigabytes of shows and proved incredibly reliable.

Anyway, now is the time to upgrade, and I want to solicit help and advice from you ‘orrible lot before I do the deed. Has anyone upgraded a myth box from Breezy to Dapper or just installed from scratch on Dapper? Some points I will need to consider about the upgrade:

• I will be building MythTV 0.19 from scratch. Any gotchas involved in building on a Dapper box? I am building because packages are not available for Dapper, and no, I am not going to run Edgy.
• Kernel 2.6.15 and above should have support for my DVB card (Nova-T) as well as my PVR350 card. Do I need to bear anything in mind to make these two play together nicely?
• Has anyone got MythGame and MythBurn up and running OK? Also, is anyone aware of an infrared arcade stick so I can play Bionic Commando from my couch?
• Finally, can anyone recommend a good way to get current things off my box and converted to something usable (such as MPEG4) before I do the deed? I believe nuvexport could be useful here. I tried mencoder to convert from .nuv to something else but there were lipsync issues.

People, share with me your experiences…

Posted on July 28, 2006 - by jono

Diversity is our strength

It has been oft stated that diversity is key for the Open Source community to develop. You don’t have look far to see how diversity plays a key role in software development and community infrastructure construction. We demand not only diverse skill sets (artists, developers, documentation writers, usability engineers, musicians etc.), but also diverse levels of opinion, culture and philosophy. With our community ingrained in a distributed web of network-connected people, we have had to respond and mobilise to culture so as to ensure that a western majority does not dominate the entire offering. As such, our software is localised in a huge number of languages, it takes account of subtle cultural differences, and the average Open Source developer works with such diversity on a daily basis.

Although things are bright and rosy on one level, diversity also brings its own collection of challenges and difficulties, and some of these problems have not been solved yet. I want to focus on two areas in this post – diversity at the project level, and diversity at the human level.

The project level

At the project level, diversity is essential in all but a few projects. Traditionally, diversity was “choice within a relatively restrictive persona”. This manifested in debates about vi vs. emacs or KDE vs. GNOME. Many onlookers heralded this as a new era of software choice and diversity. Sure, we have choice, but what I am getting at is real diversity at a project level, not just technical decisions.

Since my introduction to Open Source just under 10 years ago, I have worked on a range of projects, and each has had their own levels of diversity required. As an example, Linux UK demanded diversity of journalistic ethics as well a technical team to build the site and ensure it was well developed. LUGRadio regarded a different type of diversity as the community was constructed, and today, Jokosher needs an entirely different approach.

Diversity is not just about getting people with different skillsets involved in a project. It does not manifest in just having nice icons, well written documentation or solid code. It is not just about having different packages, a translated website or a frappr map with users from around the world. These elements form part of the diversity challenge but there are many other issues at play also.

The challenge of diversity is the ability to bring into a project different types of expertise, optimise their contributions, define solid milestones, develop autonomy and refine inter-skill communication. The goal of diversity is similar to the goal of good design an usability – to define an eye for detail, and back that up with good practise, solid implementation and the ability to measure progress efficiently. It all boils down to an ability to understand the importance and severity of different aspects of an application/project and never minimise that importance where it should be raised. As an example, the importance of good design and usability often gets overlooked in many projects, so does the importance of consistent icons, strong documentation and ease of use. These issues are typically seen as secondary to piling in the features, revving quickly and creating ‘cool new stuff’.

The prioritisation problem is born of natural human instinct – to refine and prioritise those skills that are (a) easily accessible or on tap and (b) are just plain fun to work on. To ensure these different aspects get the respect and importance that they deserve, it demands a higher level approach and someone with an oversight orientated approach to the project. This person essentially acts as a community manager who ensures that the wheels are oiled in each of the different teams, and works to encourage, inspire and foster development in each of the different parts of the project. We have people doing this in a range of projects, and this has been my role in the Jokosher project. I am not in charge, but I work to ensure we can get the most out of our different teams.

The key here is actually having those teams in the first place. Sure, we are a small project, and our teams all number less than 8 participants, but each team has its own direction, culture and social structure. If you take our art team as an example, Oscar is leading the team, and he is working with the other chaps to define a best practise for Jokosher art. There is a little sub-culture working there, and it can only mean better art for Jokosher. I have been working to develop a bunch of teams like this, and they are really getting on their feet and doing some great things, and with the recent i18n code in Jokosher, I am also working to build a Translation Team. Apply within…

Although constructing these different teams is one aspect of building a diverse community, the real key is how the teams work together. This boils down to interoperability, advocacy and a common culture across the entire project. Since the beginning of the project there has been a strong culture of openness and regular feedback. There has also been a culture of separating skills into the different autonomous teams, but ensuring there is a strong project-wide connection. This is why there is a single Jokosher mailing list. If we had multiple lists it would fragment the community – we instead want each team to feel like a unit, but to integrate well into the bigger picture with as little red tape as possible. Part of the reason why it has been so useful to have an oversight over the entire project is that there is someone fairly unambiguous to help foster these connections. This is all about best-practise, and best-practise isn’t about putting rules in place and forcing people into boxes.

The people level

I have been thinking a lot about diversity at the people level recently, partially sparked by the interesting talk given by The Women Of LUGRadio at LUGRadio Live. The talk looked at why women may get a less than equal experience when coming into the Open Source or IT industry, and how we can smooth these problems. Three prominent members of the LUGRadio community (Kat, Jen and Phated) gave the talk, and it caused some great discussion. I am pleased to see that Jen is following this up and looking to spread the message and do some interesting things. I think the important thing to focus on here is first how we identify how prejudice affects different groups, and secondly how we go about solving the problem.

I am not going to go into all the details of prejudice and my opinions and thoughts around it, but I think there needs to be a strong sense of grounding to the discussion. From what I can see, most of the problems that women have identified when coming into the community are problems not specific to women, but also other groups. I am sure many readers of this blog have experienced some kind of prejudice due to colour, creed, age, sex, accent, political persuasion, sexuality or other areas. Sure, women are affected by many of these issues, but this is a bigger problem with prejudice, and we need to be careful not to zone in on one group affected and not the others.

Bringing it back to diversity, I think we need to identify how different groups of people can again bring different benefits, value and perspective to the community. I am keen that we should not be afraid of our differences for fear of being offensive or putting someone in a group, but we need to encourage areas in which we can bring value. The key here though is in not dissuading people from the community just because of who they are – lets encourage a women to participate because of her particular skills, but whether or not she uses those skills, lets not outcast her because she is a women. And, importantly, we need to encourage adoption and integration into our existing community and not develop splinter groups. The GNOME Womens Outreach programme does this perfectly – it encourages women into an existing diverse community, as opposed to creating a separate community just for women who want to contribute to GNOME. This is the right way to do things.

I am keen to get everyones thoughts on this – do leave your comments.

Posted on July 27, 2006 - by jono

Mmmm, LADSPA foo

Well, after yesterday’s design post I have started implementing it in Jokosher. Currently the dialog pops up and you can select a LADSPA effect, add it to the instrument and configure the effect settings. The settings are mostly saved at the moment, although there are still some bugs, which I suspect are to do with data types or range problems.

So, the LADSPA support is largely ready in Jokosher. When a friendly GStreamer developer fixes the bugs in the LADSPA bridge, I can test to see that it works fine.

Posted on July 26, 2006 - by jono

All your effects belong to us

Audio effects support in most audio editors suck. The actual quality of the effects is not a problem, in fact, the effects bundled with Cubase SX 3.0 are incredible. The problem is in terms of the user interface and integration. The value of effects is critical in a studio – it is effects that add subtlety, professionalism and the feeling of a great recording. Take an electric guitar for example. If you record a dry electric guitar and don’t add any effects, it sounds rather plain and boring. If you pan it in stereo, add compression, a little reverb and work the EQ, you have an entirely different sound. Clearly, effects are important, and users need to be able to get to them easily.

This week I have been thinking about how to best represent effects in Jokosher. Before I started to think about a design, I first looked at the existing problems with effects support in competing multi-trackers. They are:

• Effects are typically assigned independently to independent tracks, with no knowledge of the physical world. There is no way of figuring out which effects make sense with which types of tracks. As an example, I want to know which effects make most sense with a guitar and which with drums, cello, bass or vocals.
• The order of the effects is essential. Most multi-trackers make effect ordering difficult.
• Effect support in other multi-trackers often suffers from ‘button overload’, with stacks of buttons, controls and other clutter filling up windows.
• Many effects in competing applications use unusable controls such as rotary dials and knobs. These are difficult to control with a mouse.
• Templates are often limited, badly documented and difficult to use.

While thinking about these problems, drawing some sketches and applying some information flow, I have developed what I consider to be a fairly solid design:

When thinking of a proposed UI, my first consideration was to lay out the effects chain from left to right. Many people (in left-right writing countries) think in this way, and it also maps to stomp boxes that are a familiar sight within guitarist’s bedrooms everywhere. When the user wants to apply an effect, they apply it to a specific instrument, and the above dialog pops up. With the Jokosher design thinking in terms of instruments and not tracks, it gives us a number of benefits that can be used to help choose the right effects. In the above design I have made the assumption that the user is adding effects to a guitar, and you can see the guitar on the left side of the box.

To add an effect, the user selects it from the top-left combo box and clicks the + button. the effect is then added to the right of any existing effects in the center of the dialog box. The user can then re-arrange the order of the effects by dragging the boxes from the left to right. If the user wants to configure a specific effect, they click the effect button in the middle of the dialog and the settings window for that effect pops up.

One of the main problems when designing the UI was making the process of selecting a specific effect and placing it in the right order simple. On one hand you could select the location first and then add the effect, or you could select an effect and add the location afterwards. After fighting with these issues for a few hours I came to the conclusion that most musicians don’t actually care about the ordering of the effects. The user will simply want to (1) pick an effect and (2) hear it. This is why in my current design, the new effect is automatically added to the right of existing effects. This way, as soon as you see the dialog, you can select an effect and add it to the chain – if you want to re-order the effects, you just drag them left and right and the other effects re-order automatically.

Another problem I faced was making it easy to apply similar effects to lots of tracks. As an example, when I record LUGRadio, I apply compression and EQ to all five tracks. Currently I have to apply this manually, and it is a pain. Unfortunately, there is no easy way to do this from a specific instrument’s effect dialog (I spent hours trying to solve this), so I have deferred this as an issue that effects presets solve.

Speaking of which, let me explain how effects presets will work in Jokosher. One of the problems with effects plug-ins is that there are tonnes of effects, but its difficult to know which ones to choose, and how to combine them to solve a particular audio problem. It is like having a collection of paints and not knowing how to make the right shade that you want. This has been in the forefront of my mind since the original design, and this is part of the reason why I wanted to ensure that we don’t use tracks and instead use instruments. When the user selects an instrument, it not only maps the physical world to the virtual world (a guitar in the physical world is recorded in Jokosher as a guitar instrument), but it also limits the scope for that instrument. This means that we make reasonable guesses for the types of effects used on that instrument.

As an example, lets say I add a guitar to the composition. In the effects dialog above, the top right of the dialog would then contain a series of presets for guitars. As an example, one preset may combine certain compressor, EQ, delay and chorus settings to make a great metal guitar sound. We could also have presets for rock, blues, acoustic, and others. Sure, it means we depend on certain LADSPA plug-ins, but I am more interested in delivering a solid user experience than worrying about dependency issues. Presets will make Jokosher simple to use, and a suitable preset infrastructure will make people able to distribute presets easily. This is all planned for 0.2.

In the above dialog design, the presets combo is on a shaded area. I wanted to ensure that presets are ‘part of the furniture’ when it comes to dialogs and not a specific control to that particular window’s context. This is why I used the shaded area, and it is why it is in the top right part of the box – this makes the weighting of the dialog make sense when it comes to diagonal reading patterns. The presets will be across a number of different dialogs where it makes sense.

One of the issues in terms of dealing with LADSPA plug-ins is that the GUI for each plug-in needs to be auto-generated, and I have already got some code up and running for this. Although this will be the case for the vast majority of plug-ins, certain specific plug-ins, namely compression and EQ will have custom UIs designed for them and be built into Jokosher not as plug-ins, but as features (they will still use the LADSPA plug-in though). This is because (a) virtually all users will use those features, and (b) EQ in particular does not map well to horizontal sliders and instead needs vertical controls. All LADSPA plug-ins that are used in Jokosher will be hooked into the preset engine so that LADSPA plug-ins can have sensible presets shipped with Jokosher.

With the UI side of things solidified in my head, I am going to start coding it up. I will keep you posted.

Posted on July 25, 2006 - by jono

LADSPA support coming to Jokosher

At LUGRadio Live we agreed an initial feature-set for Jokosher 0.2, and a release schedule. For more details on this, read this this thread.

One of the key features I am keen to see in 0.2 is full LADSPA support. For those of you who have been living under a rock, LADSPA is a plug-in standard for audio effects. There are stacks of plug-ins out there, and we want them to work inside Jokosher. So, how does this work?

Well, there is a GStreamer bridge that worked with 0.8 and was ported to 0.10 and has problems. I have reported this as a bug and hopefully some of the GStreamer guys will fix this up soon. In the meantime, I figured I would write some code to get the plug-in UI up and running.

LADSPA does not actually provide a user interface for plug-ins. I was under the impression that some kind of XML UI description schema (similar to Glade) was available to describe the UI, but it seems not. Instead, you need to probe the LADSPA ports (the virtual knobs on the plug-in) and generate the interface yourself. I figured I would see if the GStreamer LADSPA bridge worked with regard to exposing these ports via GObject properties.

So, I wrote a test script today that queries the GStreamer plug-in registry for LADSPA plug-ins, and provides a list of them. When you select a plug-in, the script generates a settings window with a bunch of sliders and their appropriate minimum and maximum values. As such, the LADSPA querying and UI side of things is written and I can drop it into Jokosher. I plan on merging it in over the next few days. I hope to get LADSPA support finished for entire instruments over the following week, and when the bridge is fixed, we will have working effects support in Jokosher!!

Posted on July 25, 2006 - by jono

LUGRadio Live is over…

…and it was awesome. Thanks to every single one of you who came along – you made the months of preparation worthwhile. The blogs and write-ups are still coming in, but the general response seems to have been very positive, and the four of us are chuffed to bits.

The worst thing about the event was that I wanted to experience it in so many different ways. I wanted to sit down and talk for hours with so many people there about serious and important subjects, I wanted to be social and have a laugh, I wanted to get to know all of you while you were there, I wanted to fire up laptops and compare code, I wanted to talk about community inclusion and get people’s opinions… Ultimately I tried to experience it with a combination of the above, but I still feel like I missed so many opportunities. I suppose you just can’t be in all the places all the same time.

There are few occasions when you see true community in action, but this weekend was one of them. Thanks everyone, and thanks to the #lugradio faithful for making the Sunday night a great finale. Each and every one of you made topped off a great weekend.

Posted on July 21, 2006 - by jono

Announcing Jokosher 0.1

The Jokosher team are proud to announce our very first 0.1 release of Jokosher; a simple, usability focused Open Source multi-track studio. Since the original design and conception of the project in February, a team of developers, documentation writers, artists, testers and packagers have worked together to create a compelling first release. I am so proud of every single person involved.

So, where do you get started? Well, first head over to the brand new Jokosher website, and read the Feature List and see the Screenshots. Then hit the Download page and grab a package. After that, read the Jokosher Tutorial and also the User Guide, and finally join the Jokosher Community Forums. Jokosher is fundamentally about community, and I am really keen to build up the forums and make them a hive of audio recording chatter and buzz. We are at the beginning of a really exciting journey here, and I want you all to share in it.

Thanks to the many contributors who have helped with this release (alphabetically listed):

Chris Brown, Oscar Carlstedt, Daniel Holbach, Gilles Fabio, Jason Field, Edward Hervey, Tuomas Kuosmanen, Stuart Langridge, Dennis Lichtenthäler, Alasdair MacLeod, Robert McWilliam, Dan Nawara, Andreas Nilsson, Laszlo Pandy, Jeff Ratliff, Gregory Sheeran, Michael Sheldon and Ben Thorp.

Joksher needs YOU! So how do you get involved? Well see this page, and hackers can grab the code from Subversion here. We also have a Documentation Team, Art Team and Packaging Team. I have been working recently to build these different autonomous teams and they are growing nicely.

I look forward to seeing many of you at LUGRadio Live 2006 this weekend!

Posted on July 19, 2006 - by jono

The rail strike is OFF!

Yes, thats right peeps, the rail strike that was threatened this weekend, the same weekend as the mighty LUGRadio Live 2006 has been called off. More details here. As such, you train using folks won’t have problems getting to the event now!

Phew.

Posted on July 19, 2006 - by jono

Recognising potential through history

As an advocate and consultant, I tend to get exposed to a rich tapestry of reasons why Open Source is great and why it is not so great. I am not going going to bother singing to the choir about the great aspects, but I instead want to discuss one of the oft heard criticisms – Linux isn’t as feature rich as Windows and will never be good enough. To approach this problem, you need to divide it into two distinctive areas – feature development and marketing. Both have their own driving forces and issues. So, lets take a look at them both.

Feature development

Human beings are great at making comparisons, that’s what we do. Utterances of “my car is better than yours”, “so, why is this microwave £30 more expensive than that one”, and “well, she/he is nice, but not as nice as xyz” can be heard across the land. Of course, we are no different when evaluating software. As such, comparisons have been made from day one about Linux vs. Windows, the GIMP vs. Photoshop, Ardour vs. Cubase, Firefox vs. IE, Outlook vs. Evolution etc. In the short term, we can indeed draw such conclusions. If application A does something that application B does not, it is fair to judge application A as being the superior product, right? Well, it is not that simple.

First of all, the IT industry is ridden with ‘feature insanity’. I alluded to this, particularly in an educational context in my Unwrapping Learning Potential With Open Source post. This phenomenon manifests in the innate process of comparing two things on a blow by blow feature chart, as opposed to actually identifying if the tool can do what you need it to do. This is particularly prevalent with OpenOffice.org – many, many people can be productive and do what they need to do in OpenOffice.org, but they instead demand that it matches every feature in the latest version of Microsoft Office. So, the first rule is to actually identify which features you need, and in many cases Open Source software is fine and dandy.

The second issue is to analyse the problem with a longer term approach and look at the history of Open Source. Let me outline this with my mad Inkscape skillz:

The diagram looks at the development of the Windows and Linux desktop. Back in the early days, a usable desktop in the Windows world was something such as Windows 3.0 or 3.1. Below the Windows box you can the Linux box is further to the right. The equivalent functionality to Windows 3.0 or 3.1 didn’t come to the Linux desktop until some years later. As such, the Linux desktop was immediately playing catch-up due to its later start. Microsoft had already got in there and started building their product, with plenty of developers and money behind it. How could the desktop compete?

If you now look at the right side of the diagram, you can see that the Windows and Linux desktops are fairly level. If you compare Windows XP to Ubuntu Dapper, SuSE Linux Enterprise Desktop or Fedora Core 5, they are fairly comparable. Sure, there are certain chunks missing, particularly in vertical markets, but people are today making real-world comparisons and considering the desktop in their organisations and homes.

From this we can identify that the Linux desktop is developing a lot quicker than the competition. This proves that the Open Source development process is working, and is working at a higher rate. This does not necessarily mean we are better optimised (100,000 monkeys picking tea are quicker than 10 high-speed tea-picking humans), but it does mean we are developing quicker, and piling in the features and unique selling points.

Marketing

In this months PC Pro, Tim Danton stated that “open-source will never pose a threat to Microsoft”. His argument basically boils down to the fact that Open Source software websites are not as good as the competition – he says that many Open Source project sites consist of just plain text and links. This is clearly an issue about Marketing.

To be honest, sure, there are some pretty dog-awful websites that push Open Source projects out there, and many do indeed consist of boring black text on a white background and a few blue links. But, I would say this is rare for major Open Source projects, and is mainly the case for niche applications, and the same limitations in fascia can be applied to niche software on any platform.

Since my entry to the Open Source community, I have seen developers evolve. Back in the early days, developers were largely code heads who cared for nothing but code. Many of these developers wrote awesome code, but produced terrible websites, ugly interfaces and terse documentation. As Open Source developed and become a serious and credible platform, developers have evolved into code heads with an experience and respect for project management, release schedules, usability, documentation and marketing. Take a look at any of the major Open Source projects and you can see well organised development teams with contributors who help in many different areas such as documentation, art, websites, coding and marketing. This is evolution doing its thing, and the average Open Source developer maintains a remarkably diverse range of skills and appreciation of these different areas. Open Source development process and practice basically grew up as the platform grew.

We have a strong, diverse and fast developing platform, and the really exciting time is as we surpass the competition in the many different areas. This is not a one horse game – we may steam ahead in web browser technology, but we may lag in CAD software. But, as Open Source grows and the platform grows, each of these areas look more and more promising every day. We just need to look at our history to understand our future.