It returns…
To [all](https://reverendted.wordpress.com/2006/08/01/shave-your-bacon/) [of](https://blogs.gnome.org/view/bolsh/2006/08/03/0) [you](https://www.rimron.co.uk/lugradio/) unbelievers:
The Beard II: This time its personal
Making ALSA suck less in GNOME
I read [Chris’s blog](https://chrislord.net/blog/does-alsa-suck.essay) about ALSA, and it does concern me a little. I think ALSA is most definitely the right direction for us to head in, but if users are experiencing a distinctive difference in audio quality, then this needs fixing, and fixing quick. Personally, I have not noticed the difference, but then again, I rarely use OSS, so I could do with comparing them in more detail.
Although Chris’s post was interesting, one of the comments brought up what I consider the main issue:
> The biggest problem with ALSA is that configuring it is beyond any mere mortal. If your stuff doesn’t work out-of-the-box with ALSA, you have zero chance of getting it working yourself. Just try to get the optical output on that nforce4 to work and you’ll see.
Exactly. But, this is not just a problem with ALSA, it is a problem with the presentation of audio in our desktop. My question is – how much of this can we fix at the desktop level? Is there a way we can develop some sane defaults for most users, and at least make a GUI interface to sound that is simple? If you take a card such as the Delta 44 or M-Audio 1010, the configuration gets devilishly difficult due to the number of available inputs/outputs, different types of mixing etc. Even users of these high-end cards should not need to care about this kind of stuff.
I think we have a really strong multimedia stack, and GStreamer is making leaps and bounds in features and stability, but we need to nail that all important middle-ground between application-level multimedia playback and the physical sound card, and this seems to be an area that needs fixing in GNOME. This is incredibly important for [Jokosher](https://www.jokosher.org/) – we have gone out of our way to make audio production in it as usability and ease-of-use focussed as possible, but the whole user experience falls down if sound card configuration requires a degree in rocket science to use.
So, I ask you all – how much of this is fixable in the desktop, and if not, how much needs to be fixable at the ALSA or kernel layer? Also, how can HAL and FDI files help solve this problem?
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. 🙂
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](https://archivedblog.jonobacon.com/?p=579), 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… 🙂
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](https://jokosher.python-hosting.com/wiki/TranslationTeam). 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](https://www.gnome.org/projects/wsop/) 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. 🙂
Mmmm, LADSPA foo
Well, after [yesterday’s design post](https://archivedblog.jonobacon.com/?p=725) 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. 🙂
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](https://archivedblog.jonobacon.com/?p=724). 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. 🙂
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](https://mail.gnome.org/archives/jokosher-devel-list/2006-July/msg00135.html).
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](https://bugzilla.gnome.org/show_bug.cgi?id=347676) 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!! 🙂
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. 🙂
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!