Musical City Techno

Fanny’s Music, East Nashville

Cicada, cricket, grasshopper, frog. However that particular indeterminate carpet of sound occurs, it is a permanent feature of the American South. I grew up in this soup, so hearing this familiar symphony again after nearly two decades of being away felt surreal and magical.

It is the sound that framed my stay in Nashville, Music City, for three mini-conferences all held at once at the Nossi College of Art: Music City Agile, Music City Code, and Music City Data. Although tickets were sold separately, it was all mixed together, so all attendees had access to everything. I recall being initially impressed by their high-quality social media campaign, and getting to the venue the conference Crew did not disappoint.

art on the walls at Nossi

Music City Tech was well organized, well-staffed, expertly choreographed (at least from my vantage point, whatever demons they found were hidden well), and thoughtfully planned. The personal attention given to speakers made it special. The organizers were friendly, helpful, thoughtful, and courteous. Southern Hospitality was at its pinnacle here.

I would say that this all made it feel like a well-oiled, small event… except that 900 attendees and nearly 200 talks and workshops over three days isn’t exactly small. Not only that, it was the most diverse group I’ve seen yet at a tech conference, which really made me smile, as did the attention to including Music-themed talks!

I have written a few things related to my talk, The Music in Resilience (aka The Practice of Practice), so I won’t really go into it here (blog version, soon enough). Instead, what I want to embolden is this thread of confluence between musical and sociotechnical systems that I see showing up in other peoples’ thinking.

instruments on the show floor!

Before jumping into the other talks, it helps to underscore a central theme from mine that was strongly emphasized in all: being on a technology team is like being in a band. An important tool for a collaborative team to maneuver the challenges of complex systems, software or musical, is to build group intuition.

The Sounds of Software

Brett Berliner (@brettberliner)
Principal Software Engineer, Insight

Right away Brett made the connection that many people make and that I’ve heard all my life: musicians make excellent computer people and computer people love music (he has personally attended 500+ live shows). He started off by drawing a clear parallel between great team communication and people getting together as a band and practicing.

geeks geek out to the afterparty band

I felt a bit like I was lounging in a levitating gondolier, floating low above the surface, with our guide pointing out topography below of how music and coding intersected. Using himself as Exhibit A, we were shown early listening devices (boom box, portable CDs, mp3 player pioneers), logos of usual suspects in online music services (props for Bandcamp mentioned), and even headphone recommendations. He explained the methodology for choosing songs for his shared playlists, crafted for various moods and temperament while working.

Lastly was an introduction to live music coding, including something I’ve used before called ChucK, but mostly featuring a (successful!) live demo of Sonic Pi. This came before my talk on Friday, and although I normally never go to talks before I give one, I wanted to make sure I saw this because I had a feeling I could relate.

Does Your Team Groove?
What You Can Learn from a Bass Player!

David Gentry
Scrum Master, Agile Coach

A good deal of the sponsorship appeared to revolve around Agile practices and general team organization and efficiency. Part of the Agile conference track, this talk was my favorite. He even brought a copy of The Music Lesson by Victor Wooten – source material and inspiration for his subject – to give away. You know I grabbed it.

Good Groove is everything but the notes, Good Agile is everything but the process.

Right away the familiar motif returned, and “playing with other people” underlined everything, again making the astute observation that collaboration in teams is the real action of playing with people. I think he and I share the same view that this is not strictly allegorical. As such, David more strongly resonated with the subject matter of my talk, really digging into specifics, not being satisfied merely by comparison and simile.

Like I do with idiomatic improvisation and complex systems, so does David link bass playing and the Scrum Master, believing in that deep connection, feeling it himself. These relationships aren’t only useful because of being relatable to the prevalence of Music in the lives of humans, they also tickle the same cognitive space as collaboration in software engineering.

David and his bass came to play!

He covers six territories of overlap: 1) Servant Leadership as a Scrum Master is akin to the place of the bass in a band, a foundational but often not obvious carrier of the ground; 2) Congruence as the rhythm and harmony holding things together, not noticed until incorrect or missing; 3) Cadence as tempo, synchronization, pulse, and timeboxed structures; 4) Conflict as dissonance that eventually balances to illuminate resolution and discovery; 5) Space as one of the greatest things to give or receive, with characteristics of trust, self-organization, psychological safety, and freedom to innovate; 6) Groove as everything about music but the notes, or in Agile as anything except the process.

His electric bass was at the ready, playing along with simple accompaniment through a single amplifier, giving examples of each of these six in its musical context, while also showing common language used in the sociotechnical one. Triplets against dotted rhythms for Congruence and walking jazz bass for Conflict were especially good, and hey we were even ‘Journey-rolled’ once he made it all the way to Groove. Don’t stop believin’ in Agile, I guess? 😉

What is Kafka?
TicketMaster’s Data Streaming Journey

Pooja Rallabhandi (@pzralla)
Software Engineer III, TicketMaster

defunct PC store, East Nashville

What I liked about this was its connection to Music through a mature, massive, and borderless sociotechnical system that has grown in complexity over nearly half a century. After steering any hecklers away from TicketMaster’s pricing model, Pooja flew at a high level about Kafka‘s pillars, giving a brief overview of the value in persistent Commit Logs and the relationship of producers and consumers with brokers.

The T.M. Core database surely isn’t the same technology in use 43 years ago, right? Although … [queue time travel sequence soundtrack] … I fondly remember operating the TicketMaster VAX terminal at Tower Records 15 years ago, itself reminding me of the VAX at Virginia Tech we used for email 10 years before that … ok, so maybe it’s not that unbelievable. She explained that attempting to solve their problems with normal queue products like ActiveMQ simply didn’t work, ultimately choosing Kafka to front the read layer of their access model for ticketing.

Ticket order transactions go directly to T.M. Core, maybe through some other logistics prior, but nothing touches Kafka yet. That happens when the data gets aggregated and prepared for display – for example on your phone for scanning right after you bought it or for resellers, where immediate updates would be needed – and a near-real-time stream of data is required. That’s where Kafka’s speed and durability comes to the rescue, which they bolster even further with their own strong consistency guarantees by performing snapshot comparisons. It is an elegant example of the tried-and-true separation of reads and writes so familiar to efficient database usage.

afterparty jugglers and geeks converge

Philosophy vs Practice

PJ Hagerty (@aspleenic)

This one had nothing overtly to do with Music but neatly supports our central theme. The reason I wanted to check this out was not only that PJ was basically the one other speaker there I even remotely knew, not because he recommends the CI/CD tool I have most recently experienced (GoCD), not due to his self-proclaimed musicianship (I’m sure he’s a fine singing saw player), not even because he called out Chaos Engineering with a Netflix tale, but because the general topic touches an exposed nerve of mine.

The key is that teams work together, the most important part of DevOps is communication.

Nevertheless, his presentation attempted to move us away from the catchphrases so often associated with DevOps, instead dialing-in on how modern tooling supports a cross-disciplined cooperative environment. I am particularly interested in this perspective because Chaos Engineering plugs directly into concepts of group learning in a sociotechnical complex system, especially Game Days (outlined in my talk as ‘The Practice of Practice’).

He also gave a shout-out to another sociotechnical subject near and dear to my heart: SRE. Only he called it Site Reliability Expert. I think my tweet on this sums it up nicely:

This ‘mistake’ actually fit into the talk perfectly, because eschewing the buzzwords really helped make it all about practical combinations of tool and theory, and PJ readily handed out toolset recommendations by continuously relating their practicality to the overreaching philosophy of DevOps.

What is that philosophy, you ask? It’s pretty simple, and it was refreshing to hear someone else say so. Above all, the key is that teams work together. The most important part of DevOps is communication. In fact, it makes sense to think about DevOps as something that needs multiple perspectives to exist at all. Maybe DevOps is everything about software engineering except the code.

Music City

The Gambling Stick BBQ

It felt good spreading the word of Chaos Engineering and Resilience to more ears, and it was spectacular to be a part of the conference. Having been at a few conferences lately that happen on the (US) coasts, it is striking that trends and conversations around the resilience of complex systems and new ways of thinking about safety aren’t being as heavily preached in more landlocked locales. At both here and Texas Linux Fest earlier this year, the number of hands going up for the question “who has heard of Chaos Engineering” was one or less, even in casual conversations. I am finding that this subject seems to get a lot less attention in so-called ‘flyover’ areas than it would at a coastal conference. This needs to change, and my team at Verica is in the game to help make that happen.

I decided to stay over in Nashville a bit afterward to experience some of the city (and sorely missed southern BBQ), fortunate to have a friend and coworker there with whom I also wanted to spend time. So imagine my joy when she surprised me on Saturday with a message that “Duet for Theremin and Lap Steel” from Atlanta (@duetonline) would be performing that night at a sake distillery downtown.

Of course, without a moment’s hesitation, I said yes.

DFTALS at Proper Sake, Nashville


A lonely computer music lab, between practice and Early Music Ensemble rehearsal. Sitting at my workstation, the phosphor lines glow back in friendship, inviting the experience. On some other terminal across an expanse of ocean lay the eyes and hands of another typist. For one reason or another, connected to the same server, our consciousness met through ‘talk’ and the revelation hit me that this new network – in 1991 barely used by anyone but scientists and art geeks – not only passively gave us text with pictures, but also brought us together.

My synth project: complete!

Here’s something I thought I’d never see myself do in my own lifetime: build a synthesizer from scratch.

Actually it’s a simple design: 2 555 timers in astable configuration producing square-waves. This means it’s a burst of sound every interval, pretty annoying and not very useful except for maybe starting earthquakes. So to give it a little flavor, I put a low-pass, 2-pole filter on the output of each oscillator, using a traditional operational amplifier.

K2 Schematic

A bit over a year ago it started out as a learning experience for me, I had never gotten into building things with analog circuitry – although I dated a chick in college who was an EE, so I was vaguely familiar with a breadboard. As a result, my design is über simple, and in reality was the design I could “get to work” from the opamp (a weird beast in itself, I will be tackling it again soon enough).

After a lot of experimentation and research on the web (these days a DIY’ers first reference), I came up with a 2-rail power design that provided 9V for the oscillators and 4.5V for the bipolar opamp (just left of the battery in the schematic). Moving left, the 741 opamp (NTE941) provides a low-pass, 2-pole filter to the signal from the 555 timer (NTE955).

completed synthguts

The cutoff frequency of the filter is controlled with a potentiometer, as is the pitch of the oscillator. You can also see my modification in the lower left for a “range” switch, which wasn’t on the breadboard prototype, but made it onto my final PCB because I think it adds a lot more interest and possibilities.

This was an intense project, no doubt. I got some training on soldering little kits that got made into sculpture, and I am a proud builder and owner of a bleep labs thingamakit, and have recently built the wave sheild for my new arduino board (which I haven’t quite gotten to work yet, so I hope it’s my programming skills and not my soldering skills).

As much as I tried to plan out wire distribution inside the chassis where the pots and switches would not interfere too much with the PCB, sure enough I drilled the holes sort of on the wrong end of the enclosure, so the edges don’t match unless I flipped it, and of course I only discover this after everything is screwed into the front. So, fixing it meant pulling all the knobs and switches back out, and removing the PCB from its mount on the inside and flipping it 180 degrees, then re-attaching everything.

In the end it really didn’t make that much of a difference and the whole thing came together fairly perfectly anyway. What I haven’t really done is add any decoration or labels, which I do want to do… inspiration will strike when I least expect it, perhaps it will not only get illustration but also a name, and it will evolve!

New improvisations on SoundCloud

Freely improvised one-takes. Instrumentation includes homebuilt instruments, sampled objects and looping hardware.

This music sharing site is a great tool for posting various non-published tracks, as well as released stuff, and has a nice embeddable player and comment system. Really nice for being able to just slap some stuff up, I have one friend who has recently been doing the same with sessions on his new Serge Modular Creature, and another who posted “in progress” snapshots of a track he is working on.

Feel free to download and remix, just give the proper attribution. 🙂

SoundHack Delay Trio Released

Tom Erbe is one of the members of the electronic music community whose work I highly respect. Not only is most of his software free, not only are they usable by any skill level, not only are they the most educational electronic music tools i’ve ever used… I could go on. But the end result is that they sound simple and great.

At long last Tom has released the SoundHack Delay Trio, the description of the algorithms is fantastic, from the announcement:

“All of these are derived from the same basic delay algorithm: a hermite interpolated delay line with variable modulation, and a feedback loop with dc blocking and saturation. Pitch shifting is achieved with a dual head crossfading delay (ala Eltro Tempophon/Dennis Gabor/Pierre Schaeffer phonogene) and is decidedly low-fi. The saturating feedback also allows them to be great drone and noise generators.”

Awesome work! Can’t wait to get this one in action, I have something going now that begs for some new delay. 😉

Two of my other favorites of Tom’s are decimate+ and of course the ubiquitous SoundHack, both available (along with a TON of others) on the SoundHack Freeware page.