Recording With a Faster Tempo

Jun 22, 2022

Whenever I write and record music, it always seems to fall into a familiar place. About 70bpm, kinda slow and somewhat melodic. To switch it up, I decided to increase the temp and see what happens.

I played on everything except the drums.

The bass guitar was fun. I hadn’t touched a bass in about three years. I really like the movement of the bass line. Not too much, but still adds some flavor.

I kinda hated the drums I created inside Logic. I did some editing, and this feels better.

There is also a little lead guitar section at the end that I left out when I bounced the track. I didn’t really like.

I learned a bit about levels. Usually I try to record, just short of clipping. In the yellow mostly. But my guitar tone is usually pretty mellow. I did the same thing this time, but I really needed to reduce the volume on the guitar tracks. Not sure why. Maybe mic placement or the new amp. This is the first recording with the Vox AC15.

Scott Radcliff · rock-110bpm-bnc.mp3

You Should be Listening to Maggie Rose

Jun 21, 2022

A couple of weeks ago while gushing over my love of Derek Trucks and the Tedeschi Trucks Band, a friend suggested Maggie Rose to me. So I found her latest release, and almost instantly fell in love with her voice for one, but it’s really her band. They are top notch. The guitars are dynamic and subtle in the best ways. Often you can’t even hear certain parts of the keys or bass, but they are there. I know that sounds kinda bad, but it’s not. Everything blends so well together.

Here is a YouTube video of Saint. It’s wonderful. Seriously worth checking out.

Two Great Guitar Players Just Jammin

May 22, 2022

Two of the greatest guitar players in Nashville, Tom Bukovac and Guthrie Trapp, just sitting in a room and jamming.

If you like guitar even a little, check this out.

Some Sort of 2021 Review

Dec 24, 2021

As 2021 starts to come to a close, and I take the week of Christmas off, I have plenty of time to reflect. All things considered, 2021 was a good year. I celebrated my 25th wedding anniversary (I could probably stop there. That’s a feat that can’t be topped), I watched my kids continue to grow and succeed, and I had a ton of fun making and playing music.

2022 is already shaping up to be awesome. There is some stuff in the works as far as my job is concerned (I can’t talk about that yet, but hopefully soon). And I think I can take my music hobby up to the next level, and that’s super exciting for me.

This year one of my main goals was that I wanted to play guitar on someone’s record. I didn’t get that done. But I did grow in the area of recording and composing. I record somewhat regularly. I’ve learned how to use a DAW fairly well. My mixing skills need work, but I can record something and mix it so it sounds decent. I also write music a fair amount, but I don’t finish much. The flip side of that is that I’ve become pretty good at creating parts and layering parts for music.

If you know me, you know I love analyzing things. After years of studying the theory behind music, I’m now able to analyze a piece of music, determine it’s purpose, and hopefully add something to it that helps it communicate that message a little better. And I LOVE it.

This year I also considered starting something in music. I don’t know what that is. A YouTube channel, a music site, or maybe something else. I did create a not so secret Instagram account for guitar stuff (scottradcliffguitar). It’s fun when I put stuff there, and I’ve slowly become better, but it’s temporary.I imagine 2022 will be more of that. But I think there is a sweet spot in skills of software engineering and musician that could be really interesting.

But overall what I really want is more recording. My goal for 2022 remains the same. Playing on someone’s record. But it also includes releasing some stuff. I don’t sing, so it’ll be instrumental, but still fun for me.

I’m grateful and looking forward to what is next. Here is to a great 2022!

Layering Guitar Parts on Existing Songs

Dec 13, 2021

Lately I have been having fun layering parts over top of progressions of songs that exist already. A solo of sorts.

The following was written over a middle section in the key of D with the progression D A Bm G.

Here is the theory behind this. The progression four beats for each chord in the progression at about 70BPM. So the thought process is targeting chord tones at the right time, while supplying some flavor in between. It’s all D major pentatonic.

I start on the root (D) of the first chord, hit the third (F#) of that chord, and target the root (A) of the next chord. I play around a bit with A and B (the next chord in the progression), but instead of the root, I hit the 3rd (D) which also brings us back to our original tonality of D

I slide up to the fifth of the Bm (F#), pull of F# to E and land on D again. This time D is the fifth of the next chord (G).

Then I just walk that back down, playing in pentatonic and land on the D again. But an octave up this time. I run that same pattern again of D - F# - A, but this time I use a dyad (2 notes of the chord) for some flavor. I repeat the A - B thing again, but with a little more space. And go up and hit the third, for basically the crescendo of the part, and just gradually walk back down to D chord.

A Song Everyday

Feb 26, 2021

I’ve been learning and studying music theory for about three years. I’ve played instruments for years, dating back to the clarinet in fourth grade. But have concentrated on guitar since about thirteen years old. I took lessons for a few years, but didn’t really get into the theory of it until recently.

I love it. It sort of reminds me of the early days of programming for me. Lots to learn, lots to play with, and with each new thing I want to learn even more.

I plan on writing about guitar and music theory a bunch, but wanted to drop one thing here. I’ve decided to start each day with writing music. Doesn’t have to be long, and arguably won’t be very good for a while. But I want to work on getting something recorded, mixed, and mastered.

Here is day one (Sort of. I’ve written some other things, but this is the first day of the new thing.)

Scott Radcliff · 918

Blockquotes in Markdown and Elixir

Feb 26, 2021

This is the fifth post in a series about building an Elixir library. You can see the other posts here:

And again, I haven’t touched this project in a long time. Revisiting it, and checking the README, it looks like Blockquotes are up next. Should be pretty simple. I opted for just one level of blockquote for now.

Initially I thought that I would need another module like Hyperlink, Bold, or Italics. Turns out I didn’t need a new module. It’s really simple. One function does everything.

def create_blockquote(text) do
  replaced = String.replace_prefix(text, "> ", "<blockquote>")
             |> String.replace_suffix("", "</blockquote>")

Rather than doing some regex capture and then replace, I opted to just replace the beginning and end of the string if it starts with “> “. Looking at this now, I may need to update to also accept a “>” without the additional space. I’m not sure. I’ll look up some markdown docs to see if the space is typically required.

This did require one more change. I needed to update the parse method to react to a line that starts with “>”.

defp parse(text) do
  cond do
    String.match?(text, ~r/^\#/)          -> create_heading(text)
    String.match?(text, ~r/^[[:alpha:]]/) -> create_paragaph(text)
    String.match?(text, ~r/^>/)           -> create_blockquote(text)

That last line directs to the blockquote code.

While throwing data in the module to check the results, I noticed a bug. If a string has multiple newlines, it doesn’t split properly and breaks the whole thing. So I updated the split function to use a regex that looks for any number of newlines.

def generate(text) do
  parsed  =, ~r/(\n)+/), fn x -> 
    |> parse
  {:ok, Enum.join(parsed)}

Next up is code formatting. I expect this to take awhile. I see a good amount of manipulation there.

Italics, Markdown, and Elixir

Jan 24, 2021

This is the fourth post in a what is a series about building an Elixir library. You can see the other posts here:

Just as I expected, with most of the work done when parsing links was built, italics was pretty simple. I have some duplication that I would like to remove, but it’s not that important yet, and I’m cautious to add abstractions without a solid reason.

What I ended up doing it adding a pipe to create_paragraph and returning the last part of that Tuple. Maybe I could do something better here, but I don’t hate it.

  defp create_paragaph(text) do
    |> Italics.convert
    |> elem(1)

And for the italics work, I created a new module and defined very similar methods from the Hyperlink module.

defmodule Italics do
  def convert(string) do
    text = string
           |> capture_sections
           |> build_emphasis
           |> replace_emphasis(string)
    {:ok, text}

  defp replace_emphasis([head | tail], text) do
    replace_emphasis(tail, String.replace(text, matcher(), head, global: false))

  defp replace_emphasis([], string) do

  defp capture_sections(string) do
    Regex.scan(matcher(), string, global: true)

  defp build_emphasis(captures) do, fn x -> 
      "<em>#{, 1)}</em>"

  defp matcher do

If you’ve read the parsing links article, this will look really familiar. The methods almost have the same names, and they share similar responsibilities. The one addition here is the addition of a matcher function to hold that Regex for me. I got tired of forgetting to update the second place that used the same regex.

Looking at this, I can see where I could extract it. But right now it just feels like premature extraction. I like opening this file and seeing everything Italics does right in front of me.

And lastly, the tests are really simple.

  test "italicizes text" do
    assert Bargain.generate("there is some _text_ here") == {:ok, "<p>there is some <em>text</em> here</p>"}
    assert Bargain.generate("there is some _text_ here and _here too_") == {:ok, "<p>there is some <em>text</em> here and <em>here too</em></p>"}
    assert Bargain.generate("there _is some text here and here too_") == {:ok, "<p>there <em>is some text here and here too</em></p>"}

I just realized that the Italics module doesn’t have unit tests, but there aren’t really necessary. That logic is tested well enough.

Next up, bold text. I expect the same sort of path. Pretty simple.

Parsing Hyperlinks in Markdown

Jan 4, 2021

This is the third post in a what is a series about building an Elixir library. You can see the other posts here:

It’s been a minute since I’ve posted one of these updates. It’s due to a mixture of other things getting in the way and struggles with recursion. I thought I understood recursion in Elixir, but apparently not. I learned recursion so long ago that I’ve forgotten most of it. At any rate, I got it, and I think the lesson I learned is that head | tail is the best approach trying to iterate the same thing multiple times.

The problem is pretty simple in theory. Look for any part of a string that begins with [] and ends with (), extract the contents, build a hyperlink with the contents of () as the url, and the contents of [] as the link text. Then replace the []() part with the actual hyperlink. Do this globally.

The trick here is immutability. The string that you are updating must be new every time. I’ll fix that later too.

I’ll just present my working solution.

In, my main Bargain module, I updated create_paragraph to call out to a new module I made called Hyperlink.

  defp create_paragaph(text) do

And here’s the entire Hyperlink module

defmodule Hyperlink do
  def convert(string) do
    links = capture_link_segments(string)
           |> build_link

    replace_link(links, string)

  defp replace_link([head | tail], text) do
    replace_link(tail, String.replace(text, ~r/\[\w+\]\(http:\/\/\w+\.com\)/, head, global: false))

  defp replace_link([], string) do

  def capture_link_segments(markdown) do
    Regex.scan(~r/\[(?<text>\w+)\]\((?<url>http\:\/\/\w+\.\w+)\)/, markdown)

  defp build_link(captures) do, fn x -> 
      "<a href='#{, 2)}'>#{, 1)}</a>"

There is some interesting stuff, so I’ll unpack this a bit.

I will start with convert. That will take our markdown string, pull out the segments (the parts in [] and ()), build links for those into a list, and then replace them all before returning the string. Looking at this now, it should return a tuple {:ok, string}. I’m a believer that all public functions should return tuples, but I’ll do that later.

The capture_link_segments function will return a list of of those captures. More precisely, a list of lists. Given the string “This is a link and another, it would return:

  ["[link](", "link", ""],
  ["[another](", "another", ""]

And I just found a bug. That regex doesn’t handle multiple words in the link text.

Then on to build the link with build_link. Pretty simple here. Map over the list and create and actual HTML link.

Now the interesting part, and the part that gave me the most trouble. Recursion.

The tricky part is the string of text. We need to manipulate this, but Elixir likes immutability. I went through lots of very messy iterations of this. I won’t list them here, but they are in the commits on GitHub. What I finally had to do is drop back and review recursion in Elixir and write recursion code outside of this project, so I could focus on the solution. Dave Thomas explains this really well in Programming Elixir, a great resource. I went back to that book for review.

Turns out the solution is pretty simple. Elixir has a way of making complicated things simple, but you first need to understand the complicated thing.

By using head | tail I was able to constantly iterate of the collection until it was empty. And by passing in a string as the second parameter, I was able to constantly build a new string until I was done. The meat of the recursion is in the first replace_link([head | tail], text) function. The match to just return happens in replace_link([], string).

As long as the first parameter has something in the list, it will fire the string replacement operation. If it’s empty, it just returns the string. It took me days to get here. Those days are just a couple of hours here and there, but still, a very long time. Hopefully, I’ll remember this pattern going forward.

Next up is fixing the bugs I found, then italics, bold, etc… I should be able to reuse some of this recursion logic to complete that.

Update: The fix for multiple words was simple. I needed to update the Regex to accept word boundary or whitespace. ~r/\[(?<text>[\w\s]+)\]\((?<url>http\:\/\/\w+\.\w+)\)/. I still need to address the url part of th regex

Testing Logs in Elixir

Dec 4, 2020

I work on an app that logs a bunch of data. Typically, I wouldn’t test logging, but we have some issues where bad pattern matching is causing some 500 errors because it can’t handle the responses we are getting.

After some poking around, I ended up on a cool way in ExUnit to test for specific log messages. But there is one major issue that tripped me u[]

The module is ExUnit.CaptureLog and allows you to pass in a function and check that the log has the message you expect.

On the surface, it’s pretty simple. assert capture_log(fn -> Logger.error(msg) end) =~ msg That will assert that Logger.error(msg) actually logs msg.

Just replace Logger.error(msg) with the function that performs the logging and your all set. Mine looks like this because I know if it got to logging something that contains webhook_received, the code executed properly: assert capture_log(fn -> Persistence.MessageQueue.log_message(event_data) end) =~ "webhook_received"

Unfortunately, I was getting a success message when it clearly wasn’t passing. I really don’t know why. What I do know is that the log setting in config directly effects this, and defaults to :warn. By setting that to :info, messages start to flow through when testing, and the assertions start to actually pass/fail accurately.

You may have already noticed that setting the log messages to info makes for a really noisy test suite. But, there is a way around that also.

I haven’t gotten to it yet, but @tag :capture_log will allow you to define which tests should report logs and which ones shouldn’t.

This forum thread was super helpful.