jonobacon@home

Today the Jokosher Hackfest happened, and we all worked on understanding and fixing some of the remaining bugs in Jokosher. I spent my time in the hackfest triaging most of the remaining New bugs, and testing some of the key ones. I am pleased to report that recording is working pretty solidly now due to some recent GStreamer fixes in CVS. The majority of remaining bugs are small issues in Jokosher.

We have also decided that the plan is to get a 1.0beta1 out on October 1st. We will then have a series of betas in which we want you all to rigorously test Jokosher as best you can. We want 1.0 to be completely rock solid.

Thanks to everyone who took part in the hackfest, I look forward to it continuing at 9pm UTC in #jokosher on Freenode.

We have an interesting situation with Jokosher. We are close. So. Very. Close. Just a little more bug fixing and we can get out a release that everyone can use reliably.

However, we need help. We need people to come and test Jokosher, and to bug-fix where possible. To make this easier to get involved, we will be running a number of hack sessions. These are scheduled sessions when the Jokosher team will be in #jokosher on irc.freenode.net. It is an ideal opportunity to come and help.

The plan is simple:

Not everyone can fix the bugs, but everyone can help test and find out more information about the cause of the bugs. Think of it as a software version of Murder She Wrote.

We have two hack sessions scheduled this week - Wed 12th September and Thurs 13th September, both from 9pm UTC in #jokosher on irc.freenode.net. They are quite late as that is when many of our hackers seem to be around. There will also be people in the channel before the hack session.

I am also going to try a little experiment and invite people to join a conference VoIP session while we work. This could create a productive atmosphere so we can chat to each other when exploring these bugs. Initially I am going to use Skype to see if this works, with the hope of using a free software VoIP phone in the future. So, if you come to the hack session and want to join the conference call, come armed with a Skype ID.

I hope to see you there!

Hello everyone. I like Jokosher. I think its a cool piece of software, with the right direction and a great bunch of people working on. Sure, I am biased, but nonetheless, Jokosher is an exciting project that has the opportunity to really redefine how we record music on a free software platform. But we have a problem…

…we need more testers. We need more people testing Jokosher, finding problems and reporting those problems. Now, some people are doing this and reporting bugs and reporting things on our excellent forums, but what would be really useful would be if some people could have a go at debugging Jokosher, and this in turns means being able to debug a GStreamer application.

We had a meeting about the new Jokosher QA Team yesterday and I agreed to write up a quick guide to getting started doing this kind of debugging. Hopefully this will help some of you get started in this incredibly important aspect of Jokosher. If you read this guide, it should give you a good solid grounding in how to debug Jokosher and contribute essential debugging information to our developers who can fix the problems.

A bit of preparation

Before you begin, I recommend you get a quick overview of how GStreamer works. You basically need to know that you string together elements (plugins that do something specific such as reading in a file, decoding music or applying effects) and those elements are linked and have their pads connected together. I wrote a few little guides that explain how GStreamer and Gnonlin work. Although these guides cover how to write code, read them and understand the theory in them and it should give you a firm grounding in GStreamer. They are at:

You should also take a look at the diagram of the Jokosher pipeline:

This pipeline shows all of the elements and how they fit together in Jokosher.

In terms of software, it is recommended you are running Jokosher from SVN trunk and running a CVS copy of GStreamer. Instructions for this can be found here.

Getting started

The first thing you should do is initialise your CVS GStreamer setup. If you are using the guide linked above, you run a script that initialised CVS GStreamer for you. For me I run:

jono@forge:~$ bin/gst-head

The next step is to find a bug to work on. Take a look at our bug tracker and find a bug to do with playback or recording. This bug should preferably include some steps to reproduce the bug.

The next step is to run Jokosher in debug mode, reproduce a bug and then explore the log file. To do this, move to the directory where the main Jokosher code lives (namely where the JokosherApp.py file is present) and run the following command:

jono@forge:~/jokosher/trunk/Jokosher$ GST_DEBUG=3,python:5,gnl*:5 ./Jokosher -g > log 2>&1

This command does a number of things. Lets break it down:

Run the command and reproduce the bug by performing actions in Jokosher until the bug occurs. Try to remember the steps you follow - you will need to match your actions to different parts of the log file. If you get a GStreamer error message (one of the errors that says Arggh! in Jokosher) that will also be logged to the log file.

Looking at the log file

When you run the last command you set GStreamer debugging into its default mode, which rather handily adds ANSI colours to the log file to distinguish between different types of information. To understand these colours, you need to run less to look at the log file. Run this command:

jono@forge:~/jokosher/trunk/Jokosher$ less -R log

It will then say "log" may be a binary file. See it anyway?. Type y to continue. The log file will appear and you will be presented with thousands of lines of debug code. Don’t be put off though, you will be skipping through large chunks of this code.

The debug log consists of a bunch of different types of information. A typical line looks like this:

0:00:06.855443000 15857 0x8249040 INFO   GST_ELEMENT_FACTORY gstelementfactory.c:377:gst_element_factory_create: 

creating element “bin” named “Volumefadesbin”

If you look at the above line, there are two key bits of information you need to be aware of. The INFO bit tells you the type of debug message this line is and the content to the right of it is the message itself. There are a few different types of message:

…and I believe there is an ERROR type as well, which are GStreamer errors. I seem to remember seeing this, but I am not 100% sure.

To the right of the type of message is the actual log message, which in the above example is GST_ELEMENT_FACTORY gstelementfactory.c:377:gst_element_factory_create: creating element "bin" named "Volume_fades_bin". In this message a bin called Volume_fades_bin is being created.

You job now is to read through the lines in the debug log, matching the different parts to the elements and connections in the pipeline map, and try to figure out where the bug is occurring. Reading the log will be rather confusing at first, but after a few times you will get the hang of it, and after asking some questions about what debug messages mean, you will get the hang of how to understand the log file and see what is going on.

The log file is chronologically organised - the content is appended to the file as Jokosher runs. When Jokosher initialises, the pipeline is constructed, and as different things happen, the pipeline is updated and adjusted as Jokosher runs. So, as an example, when you add an instrument, a sub-pipeline (a small bunch of elements that are part of the wider pipeline) is added to the main pipeline. When this happens, some elements from the main pipeline need to be un-linked, the new sub-pipeline created and then hooked into the main pipeline. You can see how this works by reading the log file and tracking how the pipeline map is created.

Aside from GStreamer debug messages, there are also a number of debug messages written into Jokosher by our coders. The -g switch that you pass to Jokosher switches on these debug messages so they are saved in the log file. If you search the log file for python you can see these messages. You can then search the Jokosher code for Globals.debug to see where the debug messages are added. So, as an example, imagine this line in a Jokosher source code file:

Globals.debug("foo bar")

This line would generate the following debug log message (as an example):

0:00:06.896163000 15857 0x8249040 DEBUG       python Globals.py:147:debug: foo bar

So you can match the contents of the log file to different bits of code.

Navigating the log file with the less command uses a few keyboard commands which you can learn by running man less and reading the information or by reading about it here. The key skill is typing a slash and a search term will highlight the search term throughout the file (e.g. type /myterm will highlight all instances of myterm in the log file).

Debugging is like forensics in CSI - you piece together a picture of the crime from the evidence you have, the main evidence being the pipeline map (which shows the GStreamer structure inside Jokosher), the debug log and the actions in Jokosher that were performed to trigger the bug. You use this evidence to narrow in on the problem. It is a fun, challenging and rewarding process when you explore the evidence and then discover what the bug is. They key thing then is sharing your findings with the rest of the team so that the bug can be fixed.

You should share any findings on the bug report of the bug you are investigating. If a bug report does not exist yet, create one and add your findings.

Getting help

Debugging is a science that cannot be learned in a single evening, and you will need to ask plenty of questions as you learn to debug. Do hang in there though! Debugging is an incredibly useful thing for you to do to help the Jokosher project. You are welcome to ask questions in #jokosher on Freenode, post to our mailing list or ask in the Jokosher forums.

Good luck, and thanks for getting involved in this fun, exciting and important project. Feel free to ask questions or clarify points in the comments on this blog entry!

With the recent release of Jokosher 0.9 we are begging the Open Source community to test it and provide some valuable feedback that we can use to fix bugs. The problem is that debugging problems and issues to provide feedback for developers can be difficult if you have never done it before. Well, this Sunday you can attend an IRC meeting to give you a simple introduction to testing Jokosher.

Organised by the new *Jokosher Testing Team, the session will cover how to test Jokosher, provide useful debugging information and submit it to the developers. If you are not a coder and really want to help the project, this is an excellent, nay essential way of contributing.

So, head over to #jokosher on Freenode at 4pm UTC on Sunday 10th June 2007. We look forward to seeing you there.

More details on the session..

Jokosher 0.9 is out! Go and download it! If you are running Ubuntu it is as simple as installing two packages. Even easier on Gutsy, it is available in the repositories.

Please, please, please test it, report bugs and share your experiences in our forums. We are gagging for feedback about what does and does not work. I heard that a starving puppy is saved every time someone tests Jokosher and gives us feedback. Must be true. do your bit for Jokosher and puppies around the world.

Thanks to our excellent development team who have all worked exceptionally hard on this release. Easy to use audio production on a free software Operating System gets a step closer…

Lots of Jokosher news to report. Once again, I am going into bullet time to keep this short and sharp:

We are building towards the 0.9 release. If you are running on Feisty you will have all dependencies apart from an updated Gnonlin which you can download here for i386 and AMD64. Thanks to John for the packages. The Jokosher source package is available here - we are waiting for a bunch of distribution packages before we add the release to jokosher.org. Do go and test the release and report bugs and give us feedback on the forums with how you get on. You can also access us in real-time in #jokosher on Freenode. Michael Sheldon has been hacking on the network instruments support in Jokosher as part of Summer Of Code and posted an update on his progress, complete with screenshot. Great work Mike and very exciting progress! Great to see another song produced in Jokosher. Niels Kjøller Hansen has details in this blog entry. You can also read about it in the Finished Work forum. We want to see more things produced in Jokosher - do let us know in that forum! Great to see that Jokosher is in the top 15 Open Source projects to watch. Bring it on. There is a meeting on Sunday at 4pm UTC in #jokosher to discuss the plans for 1.0. Be there! While at the Ubuntu Developer Summit I got chatting to Tim-Philipp Müllerabout multi-input sound card support, which Michael Sheldon was working on. Well, I am going to buy Tim a Delta 44 sound card soon so he can test and hack on the code. This should mean this support should come quicker with Tim onto it and his background in writing GStreamer elements. At LUGRadio Live 2007 on the 7th and 8th July 2007 in Wolverhampton, UK there will be a strong Jokosher presence with Laszlo Pandy speaking about Jokosher, a Jokosher BOF, and a number of members of the Jokosher team there including Michael Sheldon, Aq, Ben Thorp and myself.

Its all good. Lets kick some arse in the multi-track department.

Jokosher fans, time for an update.

The 0.9 release was delayed for quite some time due to a nasty bug in Gnonlin which has now been fixed, and we awaiting the legend Hervey to make his Gnonlin imminent release with the fix in before we make our release. This delay has in-turn caused a delay in Jokosher development, but I have good news to share.

Jokosher HEAD is now unfrozen. Laszlo branched 0.9 and hacking is now continuing for 1.0. The roadmap for 1.0 is not decided on yet - there will be an IRC meeting to discuss what is planned sometime soon, but the main plans are getting the current current code mature and well tested.

We are screaming out for more people testing Jokosher, particularly the editing tools. When Edward release Gnonlin we are hoping to get some updated Gnonlin packages built for Feisty and then Feisty is an ideal platform for testing Jokosher - it includes the required version of GStreamer. If you are a Fedora bod, fear not though, Snecklifter has been working on packages for you folks too.

If you are interested in helping the Jokosher community, head over to our forums and get involved.

I was delighted to wake up today and see Jimmac’s Jokosher Waveform Mockups.

This is one of the things I love most about Open Source and collaborative development - we all have our different skills and abilities, and when you take someone such Jimmac, with his excellent artistic abilities, it sparks new ideas and thoughts within a project not typically dominated with such abilities. It wouldn’t surprise me at all if some of these ideas get implemented in March when we lift our feature freeze.

This is what free software is all about - working together with our different skills and abilities, united by common goals to make really incredible applications.

Adam Gautier has been kind enough to split into parts the Jokosher talk I did at LCA and put it on YouTube. So, Jokosher fans, check it out.

On Friday last week, Jokosher hit its feature freeze. This means that no new features will enter Jokosher and the next month will be spent purely on bug-fixing. As some of you will know, there has actually been little major new functionality in Jokosher since 0.2 - this release is about bug-fixing and getting Jokosher streamlined, sanding off the edges and getting it stable.

Now, we need your help. We really, really do. We want Jokosher 0.9 (the next release, scheduled for a March release) to be rock-solid. We have a month scheduled for bug fixing, but we need to know your bugs. We need you folks to test it and report problems to us so we can fix them. Without lots of testing, Jokosher will simply not be stable enough. If we all work together, we will have a rock-solid Jokosher on our hands.

So how do you do this? Well, I have written a simple little guide. Testing is a pretty simple process and requires no programming knowledge - it just means you test Jokosher and tell us when it screws up. So, go read the guide and help us test it and make it kick some arse.

We also have our Jokosher Forums as a place to discuss the application and your experiences testing it. Specifically, the Help Forum is useful for testing related discussion.

I am serious here - we really, really need your help testing Jokosher. It is critical that we get as many bug reports as possible about things that don’t work quite right so we can nail them for the next version, which will be making an appearance in most distros when it is released. Now is the time, test it, report it, discuss it!