Reflections on my Progress

     I've been fighting with this bug for a while now. The problem is that a graph where the x-axis follows a logarithmic scale, the minimum value allowed is 20. The x-axis on this graph represents the frequency of sound in Hz, and it makes sense, to me (and probably the original designers), to have the lower limit be 20 Hz because that is the lowest frequency that the human ear can hear. However, some of the developers think that it might be useful to have it be zero for people who might use Audacity for reasons other than audio recording. You can test bass speakers at frequencies below 20 Hz and watch them slowly move back and forth trying to produce the sound. I found the 'equalization' effect source code, which a lot of it seems relevant to the bug (the graph is used for equalization and comes up when you select the 'Equalization' effect from the effects menu), but I'm having trouble understanding most of the source code included in it. The file is over 3000 lines of code, after all... I've found a few things in it that I could almost swear would cause the problem, but when I save and rebuild, the lower limit is still at 20 Hz. The first thing I found was an array of doubles, which starts with 20.0, and the rest of the numbers in the array highly correlate to the values along the x-axis, so I tried changing the head value (again, 20.0) to 0, but nothing happened. There's also some places in the code which set a 'lowLog' equal to the log base 10 of 20.0. I changed these to 1.0 instead of 20.0 because the log of 1 = 0, which is what they were hoping the lower bound would be. Nothing has worked, however. A couple of times after re-building the code, it returned compile errors - so I had to undo my changes. It looks like some of the output from Equilization.cpp goes to another file Equilization.o (object?), which is affected by some changes and causes errors there.
     That's about everything I've been up to, personally. John made an outline for the online tutorial we'll be writing, which turned out good. I'm looking forward to seeing how that turns out. I suspect I'll be doing most of the editing for it after he and Joseph have some substance to it - for some reason I love proofreading other people's writing... We're also planning on meeting to work out some details for the poster. We need to figure out which program we're going to use to design it. I don't think anyone in the group has Photoshop, but perhaps there's an open-source solution out there that will suffice!

Planning to Meet Charleston

     There were a few groups from the list that I was interested in attending meetings for. My first choice is the Agile Group. Agile development seems to be the most desirable type of development for today’s employers and I think that being a part of that group would not only help increase my understanding and skills on the subject, but also look pretty good on a resume. Unfortunately, they do not have an open calendar, so I submitted a request to join their LinkedIn group. There were a couple of familiar faces from my contacts who are already a part of the group. We’ll see what their meeting schedule is like once I get an invitation.

     The second group I was interested in was the Charleston Tech Group. This group seems a bit more broad as far as topics covered, but upon looking at their ‘meetup’ website, I was pleased to find that they had a great range of interesting things in their meetings. Topics covered everything from 3D printing to Java games to Android UI development and more. There are two meetings that are being planned at the moment. The first is for JVM languages (such as Clojure) which I thought was interesting because that is what Jason’s group is using in their project this semester. The other is about UML / Graphic design tools to model process flow. This might not be the most exciting talk to attend, but I do feel that it would be educational. There is a lot of automation possible when you model a program in UML tool that can generate code based off of the UML relationships. Sadly, neither of these meetings have dates pinned to them yet, so I’m not sure when/if they’ll actually happen. It looks like their last meeting was almost exactly 11 months ago, so I’m not sure how active they are.

     The third group I was pretty excited about was the SCSLUG group – Charleston South Carolina Linux Users Group. There was a funny post on their Google+ page by someone who said: “…my Linux pimp hand is not as strong as I would like…”. It’s pretty funny, but it’s also similar to how I feel. When I first started using Linux in ’07 I was very intrigued, but also a little apprehensive. My friend that showed it to me was very intelligent and I was a little intimidated by it, almost thinking that it was only for smart people to use. I don’t think the same way about it nowadays, but I still don’t know how to fully leverage the strong points of Linux, so I think attending this group would be a great learning experience. By looking at all of the pictures they had up on Flikr, it seems like a pretty friendly group as well! Apparently, they meet every second Saturday of the month, though, so it won’t be until April 12^th before they have their next meeting. Hopefully one of the other groups will have a meeting coming up sooner. If not, I might talk to some classmates and see if they found anything else interesting that is coming up sooner. 

After the break...

     Going into the break I was pretty depressed about how my semester was going. I was doing poorly in multiple classes due to my poor attendance caused by my chronic illness. I had missed tests, assignments, and I just didn't feel good about any or it. During the break, though, the medicine I had started a while back finally started showing progress and now I'm feeling much better (still not 100%, but a big improvement). I've spoken with my professors and am allowed to make up the missed work and I'm feeling great about getting back on track. I also got an email from a recruiter at Google asking for my resume and transcript, so that is also very exciting! 

     Aside from all the non-coding related stuff, I was able to build our project from source and started looking at a particular bug. I believe I've found the exact file in which the bug occurs, now the only thing left is to pinpoint it. The file is quite but - 3600 lines of code - but I don't think it will be that bad. After reading a few hundred lines of it, I'm beginning to get a feel for the project and how it works. Some of the code was commented out, and there has been decent documentation within the code to let you know what it's doing, but of course it could be better. The code itself is descriptive as well, which helps a ton, so I'm pretty confident about fixing this but, which will be the first one for our group. It's also exciting because my group was getting nervous about my attendance and wasn't sure what was going on - I was kinda MIA, so if I fix a bug it will probably be a big relief to them, and myself as well of course.

Reflections on my Progress

     So far this semester has been slow. Sometimes I feel like I can be a little more critical on myself than is necessary, but I feel like our group has not accomplished much compared to the others. We've contributed to the Audacity wiki, and built the source code on all the operating systems as well as put the source code up on a Github repository, but have yet to do much else. The group also seems to be a little divided as far as vision for the project. There seems to be too many ambitions among us all. Some just want to fix a few bugs and keep it plain, some have thrown the idea out of writing a nyquist plugin, and another idea came up recently of writing an online textbook (much like the one we've been reading this semester) that uses nyquist as a gateway language to teach non-programmers how to program. Nyquist is a functional language that you can use to basically generate sounds and manipulate them. Apparently, even though Audacity is written in C++, it actually handles all of the audio code with nyquist - the C++ is mostly the interface and file managing. One of the challenging things I find about this project is that because Audacity is cross platform, some of the bugs are only specific to one operating system. This means that when I'm reading a bug on the BugZilla and trying to reproduce it in Linux, I find one behavior and I think I know how to approach it, but then I check the same bug on Windows and find something unexpected and I am no longer sure of my strategy, or if a fix that I apply might break it on the OS in which is was originally working.

     The group has decided on a couple of bugs to focus on, thankfully, which we hope to have figured out by the end of the break - one involving a frequency scale that does not accept a value below 20 Hz, and another more interface related one that deals with button shading so that it's more obvious to the user what is selected. Also, I'd like to catch up on my blog posts (needless to say...) not only for the grade aspect of it, but blogging also helps me to gather my thoughts about the project, the group, and everything else that's going on. It helps me reset my perspective, which in turn makes me think more clearly about the project and gives me a little boost in confidence - not to be taken lightly!