My origin story:
‍Building a streaming server for the Mac.

I have always thought of my career in product design as the natural progression of my graphic design education and many years defining experiences for websites, mobile apps, and platforms. While this is largely true, my story actually starts as far back as 6th grade. It was at that time that I first learned to design and develop software for the Mac, and made a reasonably successful audio streaming server named Current.

My interest in programming began with my fascination for the Macintosh. My family initially had a Macintosh Performa 550, but my first computer was a purple iMac G3, which I earned through chores and my parents' generosity. I was enamored with the Macintosh and its surrounding community at the time, and had purchased numerous MacWorld, MacLife, and MacAddict magazines in the months prior to receiving the machine. I wanted to learn as many details as I could about the hardware, operating system, and available software.

This curiosity was driven in large part by classmates with similar interests, primarily Adrian Sampson, who I learned had developed a text-based web browser in a program called REALbasic. REALbasic (now Xojo) is a programming environment which makes building native applications accessible by handling the more complex aspects of OS development so that the programmer can focus solely on a program’s core functionality. I was fascinated by the idea of creating real-life native applications, and through him acquired a copy of REALbasic as well as too much of his time and knowledge.

This time period in 1998/1999 was still the dawn of residential internet, and long before the iPod and iPhone catapulted Apple out of education and into the mainstream. The Macintosh community was small, and because there wasn’t much consumer software available for Mac OS, new application releases were fairly easy to make visible through websites like VersionTracker, TuCows, and MacUpdate. These were the de facto distribution channels for independent Mac developers. An individual could easily build an app, upload it to one of these sites, and get tens if not hundreds of downloads in just a couple of days from other curious individuals looking to explore the capabilities of their personal computer.

The REALbasic community was even smaller, and many programmers knew each other from “hanging out” in a REALbasic-dedicated Hotline server. I would come to spend countless hours on that server from 1999 - 2001 soaking up as much programming knowledge as I could and downloading example code that others had written.

I made small applications here and there, but in 2001 Apple released iTunes, which included the ability to connect to internet “radio stations” otherwise known as “streaming servers.” Given the slow speed of the internet at that time, live streaming was appealing because listeners could consume music and other audio without having to suffer the lengthy download times associated with just a single song.

Contrary to the ubiquitous mental image of a “server” being a dedicated machine in a large warehouse, a server simply refers to an application running on a computer which allows other computer applications to connect to it. Any personal computer can run a server environment, especially at a smaller scale where only a handful of users are expected to connect and the data being delivered by that server is small. An audio streaming server intended for live streaming fits this definition, as mp3 song data is heavily compressed, and, as I would learn, extremely simple to share with remote users.

The target user of a streaming server could be any individual with a library of mp3s and a computer that could stay connected to the internet for longer periods. A server could be administered by a single individual in an office to allow other employees to tune in, especially if the application was easy to set up. I later learned through my sales that offices and dorms were the primary environments for streaming servers.

As I played with iTunes, the technology behind streaming piqued my interest, and one day I simply asked the REALbasic Hotline server if anyone had any example code for an audio streaming server. Almost immediately I received a response, and was baffled to learn that the underlying code for streaming via Shoutcast’s ICY (“I Can Yell”) Protocol was just three steps:

There are not many artifacts remaining from my early experience developing Current other than some old source files that will open but won’t run. My recollection of the details has faded, but thanks to my old code, the Internet Archive, and a few core memories, I was able to connect the relevant dots and surface screenshots and websites for both my software and its competitors.

On its face, version 1.0 of Current was simple. It allowed users to create a playlist from mp3 files stored locally on their Mac, and would run sequentially through that playlist, looping when it got to the end.

As Current came to life, each feature became its own technical challenge and a means by which I could learn new development and software design concepts…or hack my way to an effective, albeit unorthodox solution.

I remember that to order files in the playlist I opted for up and down arrows to save on the complexity of drag and drop. The playlist itself had a hidden column containing the path to each audio file so that I could easily load and add it to the stream.

Though, the real technical challenge was starting the stream without any users connected, as the socket’s events rightfully didn’t trigger until someone connected. While it may seem silly to play to the void, I saw this behavior as imperative to the server’s similarity to a radio station, which beams its broadcast regardless of whether anyone is tuned in. I believe I initially solved this problem by adding a second socket that would emulate a user by connecting to the first, before ultimately building a more complex timer mechanism that would determine where in the playlist the stream should be when the first user connects, then initiate the broadcast in that spot.

After the initial release, my focus shifted to how administrators could monetize their streams by adding commercials. The commercials could be any audio file, from simple homespun station bumpers, to voiced promotions, depending on the size of the stream’s audience.

Unlike today’s subscription-based video streaming model, the ICY protocol was open, allowing any ICY-compatible audio player to connect to Current. Implementing a paywall would have required a closed system, contradicting the core strategy of creating a server that integrated seamlessly with iTunes, and severely limiting a station’s addressable audience.

Instead of simply asking administrators to intersperse commercials within their playlist, I preferred the idea of a dedicated library where users could control the frequency and number of commercials in succession. This added a fair bit of complexity, as a check had to be made at the end of every track as to whether the next track was a commercial or the next item on the playlist. Additionally, a counter needed to track which commercials were played, how many times, and for how many listeners, so that the system could offer the most value for server administrators.

My passion for this functionality ultimately conflicted with my customers’ needs; however, my primary motivation for commercials was the same as it was for Current as a whole: to tackle new and challenging programming problems.

Over time additional features were identified and added, including the ability to manually disconnect individual users, dynamically determine the buffer size given a test of the host computer’s network speed, and even an option to save and then queue multiple sequential playlists.

Current did well, earning me a modest sum through tiered licenses priced by the number of acceptable users. I had a business license and even enlisted my father to sign a contract with eSellerate (Owned by MindVision Software, maker of Installer VISE) for my payment gateway as I was a minor. Alongside these accomplishments though, I would learn first-hand how competition breeds the relentless need to innovate and expand.

The following products were Current's primary competitors:

Given the tight-knit REALbasic community, my frequent presence on Hotline, and relentless release schedule, it wasn’t long before Current gained the attention of other developers. One of those developers was Arctic Software. The early releases of their aptly named “iStream” streaming server didn't initially concern me, but the teaser for version 2.0 felt like a shot across the bow. They had taken Current’s interface paradigm and refined it into a sleek, modern product that looked more refined and professional than my offering. Their server log’s blue background seemed to be a taunt, underscored by its mixed-color text—a surprisingly complicated effect about which I had repeatedly vocalized my frustration.

What truly perplexed me however was Arctic’s claim that iStream 2.0 allowed administrators to “Monitor and listen to live streaming as it occurs on the server. You can get information on the amount of data transmitted and broadcast time.”
‍
I recognize now that this simply means that whomever was running the server could listen to its broadcast without connecting a player like iTunes, but I have a vivid memory of interpreting this description as the ability to connect an input such as a microphone and send its feed immediately out to listeners. While reviewing my archives for this piece, I found a saved Hotline chat between myself and another individual about how to take a microphone’s input and broadcast it in real-time. The guidance that person gave me was over my head at the time, and there it remains, even to this day.

iStream would outlast Current, but not without its share of headwinds. Reviews of iStream were frequently critical, and many accused version 2.0 of being buggy or error prone. My inability to add audacious features likely saved Current from similar judgment.

MP3 Streamer was the first consumer streaming server to market, and built in either C or C++ rather than REALbasic. This architecture made it inherently lean and stable, a trait which was emphasized by its relatively simple functionality.

Rather than managing playlists within the application, the administrator would create an audio folder next to the application on the host machine’s hard drive, then choose to either play sequentially through the hierarchy of nested folders or shuffle randomly.

The story of my relationship with Melonsoft and its founder Ryan Staake is long and includes  an attempt at collaboration on a program for writing JavaScript that we called MacLatte. His specialty was creating succinct, freeware applications that were more like experiments than commercial endeavors. Ultimately, he released LeanStream, a free streaming server limited in scope to broadcasting a single playlist, akin to the earlier versions of Current.

LeanStream’s release came after I had turned my attention away from software and toward my high school studies. My creative interests were also reorienting themselves toward graphic design rather than software. I don’t have any specific memories of using LeanStream, but my memory of Ryan would indicate that the application was simple and worked as promised.

I don’t have specific memories of this product, but do remember downloading its source code and learning that it was well above my head as it was not written in REALbasic. xStream is certainly the least aesthetically pleasing of this group, but follows a similar paradigm to its peers in regards to server settings, status information, playlist population, and listener management.

Looking now at xStream GNU and LeanStream, I am reminded that there was a period where developers couldn’t seem to decide whether each feature should occupy its own window, or be consolidated into one. Reflecting on the various versions of Current, I see that I did both, with more windows appearing in the later versions. This makes sense, as I remember that passing variables and data between windows was more difficult, as data had to be stored in memory at the app level. A notorious hack at the time was to not actually close the window when a user pressed the close button, but instead make it invisible so that the components within could still be referenced. Regardless, I think that I added additional windows in an attempt to make the primary window more visually succinct as my software design capabilities improved.

By early 2002 my attention had shifted to high school and my burgeoning interest in graphic design. The introduction of MacOS X further complicated development, and I recognized that Quicktime Streaming Server and Live365 would be the gold standard for anyone interested in broadcasting audio at scale. Over time, I lost interest in maintaining Current, and sales naturally fizzled out.

I have always cited this era as my introduction to programming, and it certainly taught me how to communicate with engineers and understand high-level development methodologies and syntax. Over the last two decades I have run frequent experiments with JavaScript. After starting at PitchBook I built a plugin for Figma that automated the creation of table components and filled them with real data from the platform.

Only recently did I connect my earlier experience with REALbasic to my career in software and UX design. Every feature I built into Current required a solution that worked, was enjoyable, and followed accepted paradigms. Those early years built a foundation of understanding that I have been able to refer to as well as expand upon in the intervening years. While software development is remarkably more complex now, it is not entirely unrecognizable, and the same core philosophies for defining functional behavior remain the same. Experience design is no different. While humans are now accustomed to greater density and more complex workflows, the individual components and interactions in those workflows have remained largely unchanged. This evolution rather than revolution is what has allowed me to apply the knowledge from those early years to the work I do today.