Hi everyone! I’ve made lots of progress in developing infrastructure for both the nonlinear and custom rulers. I’m looking forward to begin testing and showing off the changes I make through these blog posts!

Accomplished this week:

• Broke the Ruler class into separate Updater files.
• Substantially rewrote existing ruler code to follow new polymorphic Updater standards.
• Cleaned up scoping inside Ruler and Updater to be more secure.

To accomplish this upcoming week:

• Implement invalidation for Updaters with runtime type identification.
• Debug and test polymorphism.
• Develop the nonlinear and custom options.

Happy 4th of July! Progress has gone smoothly this week. I’ve been making changes to the Ruler.cpp and Ruler.h files; you can follow along at my GitHub fork.

The timeline for the project has changed slightly; I am now targeting to finish the implementation of the nonlinear and custom rulers by the end of the 5th week, with the vertical linear dB waveform ruler taking only the 6th week.

Accomplished this week:

• Reworked Ruler class to be more easily expanded upon with polymorphism.
• Fixed various minor issues in code to improve clarity.

To accomplish this upcoming week:

• Finish implementation of the nonlinear options.

Hello again! This week has been a little slower than the last due to personal reasons. Still, progress continues; I’ve began implementing the nonlinear ruler options.

Accomplished this week:

• Identified issues that could motivate later parts of the project. (Advanced two-tone labelling on rulers. refactoring existing data structures, etc.)
• Began expansion of nonlinear ruler code. Designing code that will allow any function to be passed by the instance of the ruler, so that tick marks can be placed according to that function.
• Test options by editing existing ruler instances.

To accomplish this upcoming week:

• Finish implementation of the nonlinear options.
• If possible, begin work on custom options.

Hello everyone! Here are some updates on the current status of my GSoC Project. I have mainly taken this week to gain a better understanding of the Ruler code.

Accomplished this week:

• Investigated the source code for the Ruler. Created a map of the functions and how they relate to each other.
• Created a small project to better understand labelling. Separated the font of the label’s value from the units, allowing for more dynamic labelling.
• Discussed the project with mentors and communicated goals and expectations.

To accomplish this upcoming week:

• Implement a complete suite of options for a nonlinear ruler.
• Continue talking to mentors and better understanding the code.

Hello, everyone. My name is Michael Papadopoulos, and I’m a computer science major at Rensselaer Polytechnic Institute. I’m grateful to have been selected to create a project for Audacity through Google Summer of Code. My mentor throughout this endeavor will be Paul Licameli.

The current state of rulers in Audacity

In Audacity, a ruler is any segment of the UI which measures a value on a scale using tick marks. Examples of rulers include the amplitude scale to the left of waveforms and the timeline.

In the current version of Audacity, only two types of rulers are supported: Linear and logarithmic. Developers have previously only been able to create new rulers if they could fall under one of these two categories. However, many long sought-after display options in Audacity need more flexibility than this. A prime example would be a linear decibel scale for the waveform display.

Another example of a ruler that would require more customizable infrastructure is a timeline that displays beats / bars. However, creating better infrastructure would allow for powerful new features to be created well in the future.

The goal of the project

The most fundamental goal of the project will be to overhaul Audacity’s ruler infrastructure, allowing for all sorts of linear, nonlinear, and custom rulers. This will be a major benefit to future developers and users of Audacity. The potential for more user-friendly and useful display options that could be unlocked by this project cannot be overstated.

Some key challenges will have to be overcome for this project to be realized. This infrastructure must be very adaptable to fit into the variety of roles that rulers play throughout the software. All changes must be thoroughly tested so that they work in all cases, not just one. Decisions will have to be made when choosing how much old code to keep and how much to remove.

After implementing this, I will move on to creating some of the display options previously listed. I will first produce the linear dB scale and beat / bar timeline, as well as waveform display options described here. These will be incredibly helpful to all Audacity users, especially beginners and musicians who will be more comfortable using these options. Communication with the UI design team will be critical to this phase of the project. Once these options are created, I will continue to discuss and implement new features while time allows.

Once again, thank you to the Audacity team for selecting my project. I will be providing weekly updates throughout the coding period, which begins on June 13th. I will provide links to my project’s progress on GitHub as I go along. I hope to work closely with the community, and would appreciate feedback and suggestions for options as well.