tips for ardour on linux

Problem and Audience

A broad selection of digital audio workstation (DAW) software are available for Mac and Windows computers including logic pro, abelton live, and garage band. These popular DAWs are not available on Linux (which I run on my laptop), but several good DAWs do run on Linux - including ardour. Ardour has a rich set of features, and I have enjoyed learning to use it for my simple podcast and music recording production needs. Ardour is open source (GPL) software, and I started by using the free version available from Ubuntu's package repository. I was so impressed with the software, that I eventually made a contribution on ardour.org to support the team's development efforts and get access to their more recent binary releases.

There are a few Ardour tips and tricks that I learned over my first week experimenting with ardour. First, I installed the JACK audio server. Ardour also supports using the ALSA kernel API directly. I know nothing about audio software, but it seems that JACK (think jacking your guitar into an amp) is the best way to route sound streams between applications on linux, although a lot of software still relies on the older pulse audio sound server.

$ sudo apt install jack2 -y

Next, for some reason ardour wants to pin its memory, so I updated my system's limit on locked memory. On my ubuntu laptop I did the following:

$ ulimit --help | grep -- -l
      -l    the maximum size a process may lock into memory

$ sudo cat - > /etc/security/limits.d/audio.conf <<EOM
# Provided by the jackd package.
#
# Changes to this file will be preserved.
#
# If you want to enable/disable realtime permissions, run
#
#    dpkg-reconfigure -p high jackd

@audio   -  rtprio     95
@audio   -  memlock    unlimited
#@audio   -  nice      -19
EOM

$ sudo usermod -a -G audio $USER

# log-out and log back in for the change to take effect

I am currently just recording with the laptop's built in microphone, and it turns out (on my laptop anyway) that the microphone's input volume is a little low to pick up a guitar playing nearby. Ubuntu 20 includes Gnome's Settings app that in turn includes a sound-settings tool with a slider for adjusting the mic.

Finally, when recording an audio track via the laptop's microphone, we can prevent feedback from the track's monitor (the laptop's speakers) by either monitoring a null input, or sending the monitor output to a device that does not feedback to the microphone (like headphones). An ardour audio track's mixer can be configured to monitor the track's audio input (microphone) or disk input (the files where samples are stored). Configuring the mixer to monitor the disk input effectively sends a null signal to the monitor when recording a new sample. Using headphones or muting the speakers also prevents feedback.

Down the Gear Rabbit Hole

I first became interested in audio production after watching some studio-setup videos on Youtube guitar channels like Paul Davids and Rhett Shull. Suppose you want to record a little guitar performance to an mp3 - how would you do that? First, you can just record directly to an audio-capture app on your phone, tablet, or computer. The cost for that is $0 - great!

Next, you want to be able to edit your recording, maybe record some commentary, maybe publish a podcast. You can use Garage Band or Ardour or some other inexpensive DAW software - cost for that is $0 to $50 - great!

Maybe you now want to get a good microphone. You could get a USB microphone to record a single channel directly into the DAW - something like the RODE NT USB looks pretty awesome for $170.

One problem with a USB microphone is that you can't use it as an input to an amp or a PA, and you are under the impression that things get a little messy if you try to plug two or more usb mic's into a computer to record multiple channels simultaneously. A better option might be to buy a digital audio interface - something like this Focusrite is $170, then get a couple regular microphones - this Rode NT1 kit includes a mic mount and pop filter for $269, and don't forget to get a mic stand - Amazon basics has one for $18.

Of course now that you have a couple nice microphones, then you'll want to get some good monitor speakers (maybe $100 or $200) and headphones (these are $30) to plug into that audio interface. You could then record loops to background tracks, and perform along by playing the background tracks through the monitors!

Now you're on your way to spending $1000 and who knows how much time on audio production, and you think - what kind of cameras and software would you need to capture video to publish to Youtube? Plus, maybe you need a nicer acoustic guitar with an audio pickup you can plug directly into the audio interface? Or an electric guitar with an amp? Or maybe try software modeling amps in the DAW? But you really suck at playing guitar. But recording a performance is a great way to practice an instrument - forces you to get it right. That microphone is really entry level - a better one would show how you suck much more clearly. Maybe you should get a keyboard to control MIDI synthesizers in the DAW - how does that work anyway? You need a bigger room for all this gear - maybe get an acoustic treatment for the room; make it a real little studio. You should really get a dedicated computer for production.

And they got you!

Summary

Ardour is a nice DAW package for Linux that is easy to get started with.

gradle to sbt for scala3

Problem and Audience

Scala 3 is an overhaul of the guts of the scala language type system and compiler that was recently released (in mid 2021) for general use. Unfortunately, the scala plugin for gradle does not yet support the new scala-3 build chain, so we ported littleware to scala's sbt build tool.

Porting a gradle build to an sbt build is straight forward. Both gradle and sbt define a graph of tasks for building projects, and they define the task library (types of tasks) via third-party plugins. Both system's define the task instances in a project's build graph with a user-supplied build file written in a DSL that makes API calls against the runtime. For example, the littleware sub-project in both gradle (build.gradle) and sbt (build.sbt) are similar to each other:

sbt:

lazy val littleware = project
  .in(file("littleware"))
  .settings(
    name := "littleware",
    crossPaths := false,
    autoScalaLibrary := false,
    libraryDependencies ++= Seq(
      junit,
      guice,
      guava,
      "javax.mail" % "javax.mail-api" % "1.5.5",
      "javax" % "javaee-web-api" % "8.0",
      "org.apache.derby" % "derby" % "10.15.2.0",
      "org.apache.derby" % "derbyclient" % "10.15.2.0",
      "org.postgresql" % "postgresql" % "42.2.18",
      "mysql" % "mysql-connector-java" % "8.0.23",
      "org.javasimon" % "javasimon-core" % "4.2.0",
      "javax.activation" % "activation" % "1.1.1"
    ) ++ junitRunnerSet ++ log4jJsonSet,
  )

gradle:

project( ':littleware' ) {
    dependencies {
        implementation 'com.google.inject:guice:4.2.3:no_aop@jar'
        implementation 'junit:junit:4.13.2'
        implementation 'com.google.guava:guava:30.1-jre'
        compileOnly 'javax.mail:javax.mail-api:1.5.5'
        implementation 'javax:javaee-web-api:8.0'
        compileOnly 'org.apache.derby:derby:10.15.2.0'
        compileOnly 'org.apache.derby:derbyclient:10.15.2.0'
        compileOnly 'org.postgresql:postgresql:42.2.18'
        compileOnly 'mysql:mysql-connector-java:8.0.23'
        implementation 'org.javasimon:javasimon-core:4.2.0'
        runtimeOnly 'javax.activation:activation:1.1.1'
    }
}

I am glad that the port to SBT was straight forward, but I'm also annoyed that scala has its own build tool, sbt, rather than simply invest in gradle - which is widely used for building java, Android, and kotlin projects. It would be nice if I could just learn gradle, and use it to build scala (version 3) too. The same could be said for golang and dotnet - which also implement their own build tools rather than use gradle, but gradle depends on the jvm, so it makes more sense for languages in that ecosystem. There is a trade-off between building a custom tool chain that is finely tuned for a particular domain, or using a more generic system that has a large community of users. I expect gradle to support scala 3 in a few months anyway, so we will soon have the best of both worlds.

Summary

It was easy to port littleware's gradle build to sbt, since the two systems implement a task-graph design.