Advent of Computing - Episode 88 - BEFLIX, Early Digital Animation

Episode Date: August 7, 2022

Digital animation has really become an artform in and of itself. In the current epoch these animations play out on fancy bitmapped displays, but it's origins are far more visceral. Or maybe we should say far more hacky. This episode we are diving in to BEFLIX: an early animation toolchain from Bell Labs that produced computer films on physical rolls of film. Selected Sources: https://dl.acm.org/doi/10.1145/363958.363993 - Paper on Zajac animation https://jimboulton.medium.com/studies-in-perception-a-restoration-story-241cd8c75ab1 - Recreation of Studies in Perception I https://dl.acm.org/doi/10.1145/1464122.1464130 - BEFLIX Paper https://techchannel.att.com/playvideo/2012/09/10/AT&T-Archives-Computer-Technique-Production-Animated-Movies - BEFLIX animation about BEFLIX  

Automation is the wave of the future. Sorry for the corniness, but I just feel like that has to be done in some big booming voice that I sorely lack. Automation is really where it's at. That's one of the huge features that makes computers so great. They can take a tedious task and just do it over and over and over again. They never get tired and they never ask for a break. Thus, they can just replace human time with machine time. This isn't even one of those things that has some break-even point where, you know,

computer automation didn't work initially, it looked promising, but it became profitable over time. No, none of that. It's been a big deal since day one, and it's been practical to apply since day one. There aren't many features of our beloved machines that came out right day one. Now, when I say automation, you probably have a few use cases in mind. These probably all fall into the traditional fold of nerd computer stuff. Going back to the booming voice, you can probably imagine automation with a nice assembly line in the background making cars. We're talking things like automatic business transactions, manufacturing, of course, navigation,

repetitive tasks that use a lot of math. Actually, math itself can be automated away. That's how we land on things like the MCMC method that we talked about last episode. Just set up some equations, then tell the computer to run them into the ground and maybe keep going for a few hours. If your task can be expressed using math, then a computer can very easily automate it. If your task can be expressed in terms of decision making, then once again, a computer can automate it. Some interesting things fall under this wide umbrella. We aren't just dealing with math, business, science, and industry.

We're also dealing with certain types of art. Welcome back to Advent of Computing. I'm your host, Sean Haas, and this is episode 88, B-Flix, Early Computer Animation. And yeah, I guess it looks like I've kind of been in an artistic mood lately. However, I swear this is a coincidence that I've gone from a music episode to an animation episode. I haven't planned out some master marathon of art. Before we get into the episode proper, I have some off-script announcements. I guess this has kind of become my format as of late, which, it's fine. I dig it.

Anyway. First one is, as always, still working on notes on computer history and still looking for submissions. Right now I have a really good sized editorial staff and I have some people signed on to the project for typesetting. So I have all the artifice prepared in the background. I just need more articles. If you're interested in writing anything about computer history, and specifically, this is going to be a place for anyone who wants to write about comp history. You don't have to be an academic. You don't have to have any experience. Head over to history.computer, my very lovely domain, and you'll get all the details about how to submit and what kind

of format we're looking for. Now, the next off script rambling is actually a correction. Now, I do get things wrong from time to time. Usually when I get correction emails from fans, it's things like, oh, you've mispronounced something or you flubbed a line which those are fine emails to get but usually that goes into the things to do better in the future category not issuing a correction this one is actually a correction about some of my content this correction comes in an email from leonard a listener of the show and fellow podcaster. He produces a show called Warum Klassik, which is a German-language podcast about classical concert music. Now, this is a larger email, I'm just going to read the excerpt that deals with the fact of the matter.

To quote, First, you describe the white keys on a piano as whole notes, which is quite misleading. A conventional western scale doesn't consist solely of whole steps. In most cases, there are five whole steps and two semitones. In the case of C major, the semitones are E, F, and B, C. You can easily calculate this by knowing that a typical scale has 7 steps, while an octave has 12 semitones. A whole step consists of 2 semitones, so a scale of whole steps would only have 6 steps. That leads me to the term tritone, which I'm afraid you've confused with triad.

The tritone is, in fact, the interval that results in three whole steps. In C major, that is like F to B. Like the seventh, it's an interval that's quite difficult to sing, and that's why it is, quote, forbidden in the rules of early music. And here we come to a matter that's still unclear to me. These limitations for creating single voice lines are not the rule of counterpoint, because counterpoint is always a matter of polyphonic music, but that might be something that Hiller himself wasn't aware of. The rules of counterpoint, which is really the art of setting

punctum contra punctum, i.e. note head against the other, did evolve already in the 14th century, when monks tried to harmonize Gregorian chants and found out that some intervals and progressions sound nice and others don't. Here comes again the tritone, who can be used but has to be resolved. In our case, the F should lead down to an E and the B up to a C. End of email excerpt. Now, thank you so much for the correction, and I do feel like I have a little bit of egg on my face, but it's good to point these things out. I did mention in the episode I've never been that much of a music theory buff, but I kind of got a little sloppy. I was trying to avoid going that deep into the theory to keep the episode accessible, and by doing so, I flubbed some stuff that, in retrospect, I should have gotten from context clues.

The triad thing especially gets me. Anyway, thanks for keeping me honest, Leonard, and next time I talk about music, I'll be a little more particular. So this brings us to the actual episode at hand today. Now, as most listeners know, I do put out bonus episodes on Patreon. Also, consider this a plug for my Patreon page. There's a handful of bonus episodes up right now. But anyway, the latest bonus piece I put together is on a language called L6, Bell Labs Low Level Linked List Language.

It's a weird list language that almost parodies Lisp. It's also one of the worst programming languages I've seen in my life. one of the worst programming languages I've seen in my life. When I was researching for that episode, I came across a strange educational video made about L6 back in the mid-60s. This video is the start of a very interesting thread. You see, it's computer animated. This weird L6 language was developed by the same person who made this very early computer animation Ken Knowlton

This got me thinking When exactly did computer animation hit the scene? Where did it come from? Well, it turns out the answer is in the middle of the 60s at Bell Labs With Ken Knowlton in the dressing room with the keyboard. So let's start off here with a simple question, a warm-up if you will. How would you assume computer animation started? What medium would the first digital animation appear in? My assumption was always that it must have been an outgrowth

of some digital graphics project. You know, a big CRT screen with frames drawn using a graphics tablet or other input device. You know, you just flicker those frames. It's just on a CRT, right? It's just on a CRT, right? That turns out to not be correct. Part of the confusion undoubtedly comes from how we view archival footage, or at least that's part of the mix-up in my head. There's this famous animation that came out of Bell Labs in the 60s. It shows a satellite orbiting around a planet.

The planet rotates and the satellite spins a little bit. It's up on YouTube so we can currently view it just fine, you know, with a screen. But that's not the animation's native media. It's not the correct format. It wasn't played back on some CRT hooked up to a computer over at Bell. Instead, it was recorded directly onto microfilm. The animation was played back with a film projector. This is partly what got me interested in learning more. I tend to be a sucker for anything that mixes analog and digital. That interface, the connection between the digital realm and the real world, tends to be tricky to construct. There's usually just one reason to delve into this strange space.

You're doing something so far out on the digital frontier that you can't accomplish your task with a computer alone. You have to rely on older technology while waiting for computers to catch up. have to rely on older technology while waiting for computers to catch up. So why did digital animation specifically have to rely on this bridge? Why on microfilm? Were Knowlton and his cohort really that far ahead of the state of the digital arts? That's something I want to try and find out. This episode, we're going to be primarily looking at BFLIX. That's the general name for the overall animation project that Knowlton was working on at Bell. Along the way, we'll delve into how digital images were stored, how they made it into microfilm, and how a highly specialized programming language made it all possible. Or, at least, made it all easier to automate. Plan 9 from Outer Space is often regarded as one of the worst films ever produced.

And I kind of like it. I'd also wager a guess that many of you share the same opinion. It's one of those so-bad-it's-good kind of B-tier films. It's dripping with the classic cheesy sci-fi camp. A lot of nerds seem to have a certain affinity for these kinds of films. Maybe we just like underdogs. One of the local movie joints near my hometown does this Wednesday night B-movie event once a week. During college, my friends and I used to attend these almost every week.

There's something satisfying about having a slice of pizza, maybe a glass of beer and a film with no plot and a budget measured in tens of dollars. But there's another Plan 9 kicking around. It's called Plan 9 from Bell Labs. The name is, of course, a reference to the classic cinema masterpiece. The campy classic that strains credul reference to the classic cinema masterpiece. The campy classic that strains credulity to the breaking point, really. Plan 9 is an operating system project that started at Bell back in the 80s. Why would anyone name such a big and complex project after a B-movie? Well, the easy answer is that there were some fans of fine art somewhere inside Bell Labs.

The more fun answer is this. For decades, Bell Labs was innovating at a pace that could hardly be believed, something that almost seemed right out of a bad sci-fi film. Kenneth Knowlton himself explains this pretty well in Portrait of the Artist as a Young Scientist, an essay he penned in 2004. To quote, you may be familiar with the names of people I knew there. Claude Shannon, John Pierce, William Baker, and a dozen Nobel laureates, MacArthur Fellowship geniuses, and other notables. Like Richard Hamming, who, soon after I arrived from MIT in 1962, advised me to, quote, slow down. If everyone here made more than one contribution to the Bell system in his lifetime, the system would be in chaos, end quote. The transistor was developed at Bell Labs.

Shannon basically invents information theory at Bell Labs. Both C and Unix were evil plans that came from Bell. Those are just a few of the highlights. This output alone would make Bell exceptional. highlights. This output alone would make Bell exceptional. The fact was that on the inside, Bell also had a unique way of doing things. The overall game plan was to grab up promising researchers, give them funding and facilities, then kind of just let them do their thing. Some of MIT's labs had a similar approach, as did certain parts of Xerox. However, Bell seems to have mastered the method.

Accounts of the lab, especially in the 60s and 70s, kind of make it sound like a hacker's dream. This is the environment where Ken Knowlton cut his teeth. He was one of those researchers on the education-to-industry pipeline. In 55, he earned a master's degree in engineering physics at Cornell. In 62, he graduates with a PhD in communications sciences from MIT. This is a very specialized background and kind of makes his move to Bell make sense. At the time, Bell was still a telephone company, despite its expansive labs having little to do with actual phones. Now, I will admit that Knowlton's degrees sound a little strange. I haven't been able to find out exactly what communications sciences means as far as what was in the program catalog.

sciences means as far as what was in the program catalog. It doesn't help that there is a more modern field called science communications. The best I have is a press release from the early 60s that mentions a seminar held by MIT's Center for Communications Sciences. That seminar was discussing human-computer interfaces. So my guess is that Knowlton was probably working on the more technical end of communications. I can further bolster this claim with one of Knowlton's early projects at Bell. This project would eventually be called Studies in Perception 1, but don't let the name trick you. It started off as half serious research and half prank. Knowlton had an interest in visual perception, the process by which we turn what we see into what we think. Soon after Knowlton started working at Bell, he created a massive image

and hung it up in his supervisor's office. Of course, this was done with the help of some colleagues, the urging of a friend, and well, the higher-ups were out of the office. This image, this study in perception? Well, it was a 12-foot-long photo of a reclining model, photo of a reclining model, in the nude, of course. As lowbrow as this prank was, it also represented quite the technical achievement. You see, this wasn't just an enlarged photo. It was a printout from a computer. At the time, you couldn't just print an image. The tech wasn't there. The actual project here is a strangely twisted web of connections. Knowlton had been experimenting with the idea of digitally produced collages. He figured that you should be able to create a false image in grayscale by printing a carefully crafted series of characters. This is partly drawing

from artistic traditions like pointillism, at least it's similar. Pointillism is where entire images are composed by tiny dots of points. Up close, you only see random dots in a seemingly unintelligible pattern, but from further back, your brain blends the dots together into an image. Sometimes it even creates new colors. This technique was already in use digitally in a few places. One notable example is the NBS's SEAC. By the 1960s, the SEAC computer had already scanned, stored, and reproduced tiny grayscale images. A key difference is that SEAC was using specialized hardware for the entire operation. The input was handled using a homespun image scanner. The output used a series of monotone prints to simulate grayscale by stacking them. The result was a block image of one of CX Programmer's children. Look

too close and it's all blocks, but zoom out and it's a little baby in grayscale. Nolten was on a slightly different tip, but there's probably still some custom stuff going on. He wanted to use smaller images to build up one big image. Now, I say that we're talking text characters, but that's not entirely the case. The actual provenance around Knowlton's early works are a little obscure, to say the least. In 2013, Jim Bolton made a recreation of Studies in Per perception for an art exhibition. As Bolton explains, most of the techniques that Ken used have been lost to time. One of the little specifics here is where exactly Knowlton was drawing his smaller images from. The art he generated in this period didn't use normal text, but instead a series of small symbols.

The 12-foot photo specifically was drawn from a set of 12 unique symbols. Some were recognizable, like multiplication, division, and a few symbols for little circuit elements. Others were more abstract. The set even included a fully blacked out box. Bolton points out that each symbol was actually composed of a smaller 10x10 pixel grid, with a few pixels on the edges to keep symbols from running together. My guess is that these were designed to be printed on some pixel-addressable machine. It could have been a dot matrix printer, at least that's one hypothesis. These types of printers were an improvement over old impact units. The first computerized example of the species shows up in late 50s, so conceivably Bell Labs had a few by this period.

The crucial clue here is that a dot matrix printer outputs little grids of dots, much as the name suggests. Some also support custom fonts, so the tech could be a match, however, there is an alternate possible option that's a little closer. This brings us to another partly known unknown. What's the deal with the data source? I think that's a good question to always ask. Where's the data? Nolten didn't sit down and draw a risque image on one of Bell's mainframes. The final collage was computer generated from an input dataset, which is, sadly, lost to time. Somehow, Knowlton scanned in an image. Once again, this is where I have a pretty good theory.

It comes down to a machine called the Stromberg-Carlson SC4020. This device also offers an alternative to my dot matrix printer theory. So, Knowlton started off with a photo. Bolton was even able to track down the model, Deborah Hay. According to Hay, this particular photo was taken by Max Matthews. This is that twisted web I was talking about. Matthews is better known as a pioneer in digital music. He was one of the programmers that rigged up a Bell mainframe to play Daisy Bell as a tech demo. Knowlton somehow managed to get this photo into a computer. We aren't entirely sure how, but my theory has to do with this SC4020 thing.

This was an amazingly complicated piece of technology, and one that will factor heavily into this episode. Essentially, the SC4020 was a microfilm plotter. It couldn't read off microfilm into any digital format, but it could take an input dataset on a tape and write off to microfilm. My guess is that if Bell had one of these plotters, then they probably had a way to digitally scan similar film. In practice, a digital scanner is a pretty simple device. The National Bureau of Standards had built one for SEAC in the 1950s.

There was also a ready-available option floating around. Fax machines. These devices worked off the same basic principle. You scan some type of sensor over an image and then output a varying voltage depending on what the sensor sees. At least, so to speak. Knowlton doesn't mention in anything I've read specifically how he scanned the image, so I'm assuming here that that means it wasn't some huge feat, it wasn't a new part of the project. Maybe it wasn't commonplace, but certainly it wasn't the main event.

Like I said, by context, I think Bell had some tools for this somewhere in the lab. Anyway, with the data loaded into the computer, Knowlton could then generate his collage. The actual symbolic image, the pattern of smaller font tiles, was constructed programmatically. Knowlton didn't have to sit down and drip down individual symbols. He designed a program to do that work for him. He automated the artistic process. The output, studies in Perception 1, was this 12-foot-long nude image. This is where the SC4020 factors in, and where we can start using conjecture to actually build a larger story. This was a pretty darn complicated machine. On one end, you fed in a magnetic tape that held

data to burn onto microfilm. That data was massaged and transformed into electric impulses that were used to control this thing called the charactron tube. This is, honestly, one of the cooler sounding kinds of CRTs I've run into. The charactron is essentially a high resolution CRT with a built-in font. The charactron would work in two modes. The charactron would work in two modes. You could plot data to it like a normal CRT. I've seen this referenced as a plotting or a vector mode, but the documentation makes it sound more like a raster, as in you get a grid to drop pixels onto. The text mode is less flexible, but I think this is the interesting part.

For this to make sense, we need to take a quick diversion into how a CRT normally works. A cathode ray tube is, once you get down to it, a tiny electron accelerator. Call it a home particle accelerator, if you like. You have an electron source in the back called a cathode. Up near the front, you have the anode, which attracts electrons and closes the circuit. The actual front, the screen that we gaze into, is just a thin layer of phosphorus under glass. When the phosphorus coating is hit by electrons, it glows in the spot it's hit. Electrons leaving the cathode form a beam, a ray, that blasts forwards right towards your face.

The beam is then focused and deflected by a set of coils located near the cathode. These coils are used to steer the beam around and draw images on the screen. That's how the Keratron's raster display worked normally, and how basically all CRTs worked. But here's the interesting mode. Crisp and clean text. A characteron tube has this internal character mask with a set of font symbols etched on it. The mask, sometimes called the stencil, was able to block part of the electron beams. There were also extra coils so that the beam could be steered through part of the mask in route to the phosphor layer. By shooting the beam through parts of this mask, it could be shaped, physically shaped, into little letters. The upsides here are speed and clarity.

Sure, you could plot out a letter pixel by pixel. That's good enough for almost anyone else. However, that would take multiple blasts of the cathode ray. Using the stencil took a single blast per character. Those characters were also much more crisp than manually drawn symbols. The electron beam was being physically shaped inside the CRT, so you end up with nice shiny font. with nice shiny font. The SC4020 was initially designed for creating slideshows or putting digital data onto microfilm. Once data was drawn on the characteron, a camera inside the machine would transfer the image to microfilm. It's kinda computer controlled, but in an indirect way. Like I mentioned, it takes a tape as input.

So you don't plug this in like a printer. You load up a tape with commands, then walk it over to the SC4020. These commands were pretty complicated. It's a strange computer-like instruction set. You have instructions for controlling things like the camera, plotting pixels, and plotting characters on the screen. If you were writing this stuff directly, you might go a little crazy. Luckily, Stromberg-Carlson, the SC itself, provided a tool to aid the intrepid programmer. It was called, quite fittingly, Plot. Now, this provides an interesting

example of how vendor support shapes research. Plot was a glorified Fortran library. This is, all things considered, a kind of bare-bones way to provide support for new hardware. It may have also been the most prudent solution given the era we're looking at, but there are some big downsides to this approach. Fortran was kinda an IBM-only thing at this point, so the SC4020 was only practically useful at IBM shops. Not the end of the world, but I just gotta point out the IBM death grip whenever I can. Using a Fortran library is pretty simple, assuming, you know, you know Fortran. A library basically just adds a bunch of new functions and variables into the environment here. There's

usually some more subtlety than that, but we're in Fortran land, so subtlety kind of goes out the window. This means that a library can really transform how you use Fortran. It can vastly change the language's capabilities, or at least what you have access to, while still working within the same general syntax. The general function of plot was to generate commands for the SC4020 using Fortran as an interface for the programmer. You would run plot commands which would fill an in-memory buffer with SC4020 instructions. Once the buffer was filled, it would be dumped to a tape. The tape could then be fed into the plotter to generate

your final images. This plot library is actually pretty robust. You can do boring things like drawing and plotting characters, or you can go deeper. Plot has routines to draw grids and charts. You can take the output from some Fortran routine, do some plotting, and then get a full visualization of your results. Of course, that's with all the added steps that the SC4020 comes with, but you can get nice graphs. That's something that you can't do with Fortran alone, even today. Plot also lets you define custom character sets. I assume this is really just a front-end for its more basic pixel-by-pixel capabilities. You just need to define the 8x8 bitmap for each character tile, then you can plot text using your custom character set.

The intended purpose here is to add in custom fonts. Putting this together, I think there is the possibility that the SC4020 was used for the output side of Nolten's nude print. A custom character set could have been loaded up using plot, then the actual image could have been defined in terms of those custom characters. Finally, some slides could have been exposed, and a final print could have been made. However, there is a catch to this theory. That's why I gave an alternative one earlier. During his reconstruction, Bolton was able to show that each character tile was actually 10x10. The custom characters on the SC4020 were only 8 pixels wide, not 10. So either

Nolten was using a different device for output, or he was using some custom code to generate his font tiles and then plot them on his own. I know this is becoming a bit of a tangent, but I want to close the loop here. I swear it will help with the rest of the story. The final print was actually composed of eight large rectangular panels. I haven't seen exact dimensions, but I do have Bolton's recreation to work off. Those panels appear to be larger than a sheet of paper. There are some photos of someone putting them up in a gallery, and they're pretty good sized. So I think that Knowlton was probably using the SC-4020 as some intermediary output than photographically enlarging his film.

Here's the reason I wanted to weave this larger tale of speculation. to weave this larger tale of speculation. If Knowlton was using the SC4020, if the nude used 10x10 font tiles, and plot only supported smaller tiles of custom font, then we can come to one conclusion. He was pulling some lower level tricks to get more use out of the microphone plotter. Now, we can pull in another passage from Portrait of the Artist as a Young Scientist. Quote, The lab had a new microfilm printer that exposed letters and vectors on 35mm film. Some of my friends, Mike Nall, Ed Zajac, and Frank Sinden,

were soon making simple movies with terrible vertical jitter because the camera lacked film gate registration pins. End quote. This is the final connection that bridges us into the main event. Knowlton and his colleagues were all working on ways to use and abuse their new SC-4020. Knowlton was using this and some know-how to pull a fun prank and create some unique art. His colleagues were trying to make animations.

The throughline is that their main tool wasn't quite up to the task. Soon, Knowlton would switch over from still images and start tackling the animation problem as well. And thus, we enter the realm of B-Flix, or as it was initially called, the movie language. This language evolved out of the work that Nolten and others were pursuing at Bell. The study and perception was one step towards this language. Another step came from a project Zajac was pursuing. Those jittery animations that Knowlton mentions actually amounted to something. This is one of those

spots where the timeline gets tight. In March of 1964, Zajac publishes an article in Communications of ACM. That article, titled Computer-Made Perspective Movies as a Scientific Communication Tool, with a long title, describes one of the first computer-generated animations. The animation in question was actually completed sometime in 63, with work on the project, of course, preceding that. So we probably have a one-year period where this project was going on at Bell, on the very same microfilm printer that Knowlton was using for his big nude image. The Zajac film is short, just about a minute, but in that time it shows off some slick programming. The animation shows a rectangular satellite orbiting a spherical planet.

The planet itself is rotating. Everything is rendered as three-dimensional wireframes. This satellite changes its orientation as it orbits, so you get this neat changing perspective on this rectangle. Zajac explains in the accompanying paper that we're looking at a simple mathematical model. The satellite is programmed to model a system containing a few gyroscopes and thrusters, while the planet provides a gravitational source in this math model. As with Knowlton's nude, Zajac isn't just entering in data by hand.

He's using a program to generate the final image. In this case, Zajac has this simple orbital simulation that's set to output instructions for the SC4020. The model even includes a primitive camera. There are parameters to set the viewpoint, so in theory, you could have a changing viewpoint as well. According to the ACM paper, this animation took just 8 minutes to generate. At least, that was the total computer time. I have no idea how long the rest of the process took, but we at least have a billable quantity here. Zajac is framing his animation demo as an example of how cost-effective films could be made via digital automation. The target of this new tool? Well,

Zajac never comes out and says it explicitly. However, I think this has to be a play at education or, to use a newer term, science communication. Zajac explains that his animation is able to show something that a simple 2D image can't. It shows movement in a way that's not easy to glean from a plot. That, pretty classically, is what you want for either a lecture or a presentation. This is all about explaining complex subjects in a visual way. One of the big benefits to this computer-generated imagery comes down to cost. Like I mentioned, we're looking at 8 minutes of computer time to generate 1 minute of film. That means you can make about 7.5 minutes of film per computer hour. Discounting human time

for a minute, that computer time is the only specialized resource needed. Everything else is just a matter of developing film. Now, this is disregarding the important factor. Zajac would have written a custom plot program to generate his animation. That's a workable solution, but plot was never meant for animation. It's a pretty low-level interface when you get down to it. It's good for drawing images, plotting data, and printing text. None of those features really contain movement. During a conference in 1998, Knowlton explained the transition this way, quote, And so in this environment, I tried my own things. As far as I know, but this may not be valid or

true, I'm the first person that tried to make a language for raster graphics. That was a wonderful time in my life. I wrote this two and a half page memo to my then department head, and I said, you know, it might be possible to make a more general language, not for one particular movie, but for a variety of movies. And, and he said, this sounds like a very ambitious project, but why don't you see what you can do? So I went ahead and I saw what I could do. End quote. do. So I went ahead and I saw what I could do. End quote. Knowlton would call this generalized language the quote movie language. Over time, it became known around the office, at least, as BFLIX. That's B-E-F-L-I-X, a portmanteau of bell and flix. This naming distinction isn't the most important, but I think it should be pointed out. Knowlton doesn't actually use the name B-Flix in his initial writings on the language.

The name does come later. So, what exactly is B-Flix? For one, it was surprisingly influential. At least, in certain circles. It even made it into Ted Nelson's magnum opus, Computer Libs slash Dream Machines. I kind of have a running fascination with everything Nelson, so I can't pass up this opportunity. Here's how Nelson describes B-Flix. I think it will give us a good starting point for our discussion. It also shows how people were talking about the language outside Bell. Nelson writes that BFlix, quote,

was programmed for the 7094 in the early 60s. BFlix allowed the user to create motion pictures by a clever mosaic process that used the output camera most efficiently. Actually, the lens was thrown out of focus manually, and the entire frame created as a mosaic of alphabetic characters. This did the whole thing much more quickly and inexpensively. End quote. I have a few reasons to like this passage, but there's one that trumps all others.

Nelson mentions that B-Flix used mosaics and a blurry lens to create animation frames. The actual technical paper on Bflix is a little coy about the mosaic or collage aspect of the language, so it's nice to see Nelson being more explicit. I find this part interesting because it gives us a creative throughline from Nolten's earlier artwork into BFLIX. This isn't just a language, it's a form of artistic expression. The medium just happens to be computerized. Now, I know this hasn't been a comprehensive answer to my earlier question, so let's get back on track.

What is BFLIX? We get a full description of the language in a 1964 ACM paper titled A Computer Technique for Producing Animated Movies. This is where we get the gritty details of this new language. So let's look at what BFLIX does conceptually, and then we'll touch on the syntax that Knowlton chose to implement those concepts. The overall goal of BFLIX is to provide an interface for manipulating two-dimensional images. Those images are then used to make up the frames of an animation. So, very broadly speaking, this is a data language. It's all about building a single type of data structure.

That structure is an addressable grid, sometimes called a bitmap. Internally, the structure is represented by a grid of 256 by 184 numbers, each location holding a 3-bit integer. That's just a fancy way to say each cell on that grid is a number between 0 and 7. An interesting point here is that the bitmap isn't directly addressable. You can't just tell BFlex to write a value to a specific location. Instead, Nolten gives us the somewhat confusingly named scanners. These are essentially pointers that are used to access locations on the grid. If you want to write to a cell, you have to move a scanner

to that cell and then initiate the write. At first that sounds kind of cumbersome, but there is a reason for this abstraction. At least, I think we can form an explanation. I think it's better to think of these scanners in the context of physical machines, something like a CNC machine or a plotter. This gets a little weird since you can read the values from the scanner's location, but let's just assume it's a very fancy CNC machine. On these computerized devices, you usually handle operations by controlling some tool head. You instruct the machine to move the head to some location, then perform an operation.

Move the drill bit to location 1-1, then start spinning and dive down. The connection doesn't come in from an expected place, or at least an explicit place. The SC4020 doesn't operate with these weird scanners. It does let you drop data directly onto film. However, I think that this scanning methodology was partly inspired by the SC4020. This all comes down to the device's character mode. In some documents, it's also called the typewriter mode, which is a little weird, but hey, it's a TV typewriter, I guess. This mode has a number of features, but the default mode of operation here is, well, it's just like a typewriter. You tell the SC4020 to type a character on the screen. It does so, then a hidden cursor is advanced to the next position on that line.

If you send a carriage return or the cursor hits the end of the line, then you're wrapped down to the start of the next line. I think that it's possible Nolten is pulling this scanner's idea from the typewriter mode cursor. BFLIX scanners don't auto-advance, but they do serve a similar purpose. Scanners aren't shown on screen. They're just a way to point to a place before you operate on it. They are a hidden part of the data structure, a type of metadata almost, that's used to construct your final image. There's another connection between this typewriter mode and scanners. You see, Bflix didn't operate pixel by pixel. As I've explained before, it produced images via collage.

Bflix is really just a more grand implementation of Knowlton's perception collages. Those mysterious values between 0 and 7? Well, they were characters all along. The actual graphics worked something like this. Bflix loads up a set of 8 custom characters. The SC4020 has support for just this. You can define custom fonts. These font tiles aren't as crisp as the Cinsult font, but they actually work in Nolten's favor. Each of these custom characters were selected for their overall brightness. So you have some characters that are totally filled in, on down to barely filled characters.

Using Bflix you can arrange these characters on your animation frames. Now looking directly at these digital frames wouldn't be very useful. It also wouldn't look very good. You'd end up with a rudimentary looking collage. Something like funky ASCII art. The final trick to pull all this together was a small modification to the 4020. When producing the final film, Knowlton would adjust the SC4020's camera to be slightly out of focus. Thus, the custom font tiles would be blurred. A partly filled tile

would appear as a shade of gray instead of a stark white on black. I really like this trick. Normally, Knowlton's perceptual collage is worked by relying on the human mind to blend smaller images. That works for something like a 12-foot image with thousands of tiny characters. You can step back from that. But a B-Flix frame was only around 250 characters wide. Not really enough for perceptual blending to work well. So the trick was to make the camera's lens pre-blend stuff for you. It's a cool application of the same general technique. This is all pretty slick tech, but there are still some annoyances here. For instance, Bflix didn't output every frame of your finalized animation. Instead, it only printed unique frames. Each frame had a

note specifying how many times it would need to be repeated. The final animation was then spliced together manually from this set of exposures. Workable, but definitely requires a lot of human intervention. The automation here is only relevant in one part of the overall process. The automation here is only relevant in one part of the overall process. Thus, we reach the language itself. So it's time for a soft core discussion of the syntax. What's interesting here is that BFlex is actually pretty complex for a niche language. To start with, it has layers.

BFlex actually has two levels of syntax. a low level of the language which is used to actually move around the scanners, and a high level that is implemented in lower level calls. Unlike Plot, which is just a Fortran library, Bflix is a little more complicated. Well, kinda. It's almost a compiler, but it gets kinda weird. Knowlton just explains it as, quote, a language which has been developed entirely within the framework of macro FAP. So it's a little ambiguous.

If this is an interpreter or a compiler or some other language thing. Macro FAP here is just one of IBM's specialized macro assemblers. That on its own doesn't help classify what Nolten created. Further confounding classification is the fact that BFLIX didn't output a program per se, but a set of instructions for the SC4020. You don't pass code to BFLIX, get a binary file as output, and then run the final program. So maybe we should be thinking of BFlex as a cross-compiler? This is a little point, but it's worth at least thinking about.

Sometimes things don't fit into nice rigid boxes. Anyway, we can start by looking at the lower-level parts of BFlex. This is the so-called scanner language, and in my humble opinion, it's a pretty cool name. So here's the dig. BFLIX doesn't have anything like complex syntactic structures. It's about as complex as basic. By that I mean each line is more or less independent of one another. You won't be writing out any blocks of code here. The core of the syntax are instructions formatted as tiny lists. That might sound vague, but it's the best summary I can think of. Each instruction in BFLIX is enclosed in parentheses. The instruction starts with the first argument, followed by the operation for some reason, then optionally more arguments. Also, to note, these are kinda little

functions. Some operations return a Boolean value, but that's it. You don't get to nest and chain these operations. It's a little strange, but it's passable for a very niche language. It's a little strange, but it's passable for a very niche language. In general, operations at this level deal with moving around scanners. You have up to 26 scanners in total. Any guesses to how they're labeled? That's right, each scanner is represented as a single letter. Honestly, once again, it's passable. 64 is so early in the programming game that this isn't a huge crutch.

We're dealing with a really niche language here. It's for handling animations on the SC4020. If this was a general language, well, then things would be a little different. These scanner operations are basic. You get a set of conditions for testing relative and absolute positions of scanners. You can, for instance, check if a scanner is at a specific location. You can check if a scanner is to the left or the right of a position, or how the location of one scanner relates to another.

These checks all return Boolean values, which are used in Bflix's if-then statements. The rest of the scanner part of the language deals with moving scanners and writing values. It's the usual complement of set, add, subtract, multiply, divide, plus some bitwise operations. You get commands to move a scanner to an absolute position or move it up by a relative position. So you can drop a scanner at 1, 1, write a value, then move it right 5 spaces and write another value. The upper layer, which Knowlton calls the movie language proper, is all about drawing shapes, text, and switching between frames. all about drawing shapes, text, and switching between frames. On the more simplistic side, we have instructions for, say, drawing lines of a given length between two scanners. That's kind of boring, but things only get more complicated from here. This is where we actually get into

the animation part of Bflix. When you tell Bflix to draw something, you can specify how fast it should be drawn. So you can have Bflix animate a circle being drawn. You can just as easily animate text being typed on the screen. So you could have a finished frame, or you could have the film show the frame being drawn in real time, pixel by pixel. Bflix also offers functions for manipulating the current frame. You can do zooms, stretches, dissolves, rotations, and a bunch of similar effects. So in practice, you can draw a little bug, have it scamper to the center of the screen, then zoom in to show the code that makes up the bug. That's pretty much everything you need to craft fun animations.

Now, of course, I have to add in some interesting notes about the language. Recall the initial goal here. Build a general-purpose tool for computer animation. It was all inspired by Zajac's very specific plot-based animation program. Bflix goes beyond plot in some very key ways. Plot, the library distributed with the 4020, has one huge thing going for it, Fortran. Plot's just a Fortran library, so you get access to Fortran in all its antiquated glory. Bflix on its own can technically work like a general-purpose language, but it's not nearly as fleshed out as IBM's math toolchain. You can use plot as a finishing touch to a much larger program.

You could, say, have a complicated simulation that ends by outputting a series of graphs. As Zajac shows, your math model could end by outputting a full animation. So here's the weird bit. It all comes down to FAP. What does that stand for? Well, hold on to your butts. It stands for Fortran Assembly Program. Nice buried lead, huh? FAP is a strange beast. It essentially bridges the gap between Fortran and assembly language. As near as I can tell, it allows Fortran and assembly language programs to link against each other, which means you can call assembly code from Fortran and Fortran code from assembly. Kind of nasty. So here's the deal, and this actually kind of answers the whole weirdness about compiler-ness versus interpreter-ness. Bflix was somewhere between a library and an extension to Fortran itself.

Maybe call it an environment? Maybe an extension to the environment? Maybe this doesn't solve the categorization issue at all. Anyway, the closest attempt at categorization I've seen online states that BFLIX is a, quote, embedded domain-specific language. But I don't really like that classification. First off, that's not contemporary with Knowlton's work at all.

The label seems to have been slapped on much later. Specifically, it shows up in a Wikipedia article without a citation, so dubious sourcing at best, but it kind of describes what's going on here, so let me explain. Basically, Bflix was loaded in as a super library. Something like Plot, but even more extensive. Bflix actually modifies Fortran somewhat, adding in new keywords. This gives you all the benefits of Plot, namely the fact that you can use all of Fortran to do calculations and run models, plus all the animation benefits of BFlex. This is, as far as I can tell, the best solution around for the time.

You can have all the generic data structures, all your fancy calculations, even separate files for storing and manipulating your model data. Then you can tack on some BFlex code to generate a moving visualization. It blows plot out of the water, plain and simple. There's also one other benefit to this implementation. At least, it's a retrospective benefit for nerds like me. In theory, we should be able to run BFlex today. We have good emulation for the old IBM mainframe that Nolten was working with. I think Mess has support, if I'm remembering correctly. Folk work with old Fortran all the time. It's not that hard to get old source code to compile in emulation. We even have ways to

digitize old punch cards. So if the source code for BFlex still exists, then it should be possible to run it. Now, there are two barriers here that any intrepid historian needs to cross. First, I have no idea where the code would be. Bell has restructured a number of times since the good old days, so one of the successor entities may have the code tucked in some archive. It's also possible that one of Knowlton's family members has the code in a box somewhere. That's hurdle one. The other problem would be emulating the SC4020. This, though, would probably be easier to jump over. The entire instruction set is very well documented in the SC4020's programmer's guide. I'd wager implementing that would be about a weekend's project level of

complexity. I find it something of a tempting dive myself. Like I've mentioned earlier, the SC4020 isn't anything like Turing Complete. You don't even really need a sophisticated emulator. You just need a way to unpack bytecode and then generate an image from the instructions within. My point here is that BFLIX could probably be resurrected. I also think that would be a pretty slick project for someone to take on. But anyway, let's get back to the topic at hand. With all this power, what was Bflix actually used for? Well, that gets us out of the technical territory and back into the finer arts. My first exposure to Bflix was the Epitome of Art. An educational video about the L6 language. It's actually, all jokes aside,

a pretty slick video. L6 is a list language. If you want deeper information, you'll just have to check out my bonus episode over on Patreon. It's a rabbit hole that I don't really want to dive down again. Suffice to say, L6 is all about data manipulation. Normally, that can be a little hard to describe on paper alone. I know for me when I'm dealing with data structures, they don't really make sense until I use them. Nolten was able to show how the language handled data in living grayscale using Bflix. The L6 animation is so cool because it shows changing data structures. It walks you through how a programmer would set up data structures in L6, then plays a little animation showing how memory is affected by each operation. It's slick and something that I kind of wish more

programming languages would use. I've seen the docs for L6 and watched the movie, and I think the animation gives a much better understanding of the language. So maybe it comes as no surprise, then, that the first B-Flix animations were actually meant to accompany Knowlton's first paper on B-Flix. That's right, this is literal self-documenting code. In 1970, Knowlton sat down for an interview in Filmmaker's Newsletter, and this is what I'm working off here, since it gives us some fun details on the early days of Bflix. The first practical animation took about two months to complete. Knowlton hedges that that was in parallel with the continued development of the language itself. This is a relatively short animation. It's been archived by AT&T, and their archival version

has two videos. Together we're looking at about 20 minutes of content. There's a longer 17-minute video and a shorter 5-minute, I think, test animation, but it's not entirely clear. Between these two films, we get a pretty full view of what B-Flix can do. Now, there are a few notes to make here. First, this is a relatively short-ish animation. We aren't looking at a movie. More like a presentation. Within that time, Knowlton packs in some impressive content.

He walks the viewer through the process of creating an animation, the process of creating the very film they are watching. It's a cool bit of meta-medium. Knowlton gets pretty granular with this. He starts by describing how movies work, literal frame-by-frame shots, and works up from there. We get these wonderful animations of a frame of film sliding past the camera. He works up to describing the SC-4020 with an animation of the lens and a CRT blasting electrons. He then gets into B-Flix. This, I think, is fascinating from a pedagogical point of view.

I think it's a little hard to describe BFLIX on paper. At least, it would have been hard at the time. You have instructions in the language that draw a polygon, for instance, with a given location, number of sides, and angle. That's cool in a vacuum. You can make a shape. Nice. But in practice, BFLIX is about moving shapes, moving images. It's about multiple images, each slightly different, being shown in quick succession. An animation obviates the need to

describe how a snippet of code looks once executed. You don't have to say, imagine this spinning. Knowlton's film shows the line of code that will generate a triangle, explains that it has a parameter for the angle of the triangle, then shows the line of code in a larger context. The film then animates what it would look like to actually draw a triangle inside a loop that modifies the triangle's angle. The result is simple. It's a spinning triangle, and it's shown fully live. This is something that's so simple, but also so satisfying to see. You can actually see how the code that's being shown on screen translates to a moving image. I know I'm repeating myself, but I just

really like that. I always harp on how the medium and message need to be looked at together. How the medium can affect the contents of the message, or how the contents land. Well, look no further for a killer combination. B-Flix is a language for animation, and it's best described using animation. You can't show a spinning triangle on a piece of paper. You just have to say, yeah, that'll make a spinning triangle, imagine it, if you will. That's fine, but it doesn't have the same oomph. These videos also have just some cool animations. The spinning polygons are only a start. The animation goes on to show a set of demos. My favorite, personally, is a loop that increments the number of sides on a polygon. It goes from a triangle to a square to a pentagon

on up until you get a circle. Further on, we get a ball following an arc, then lines bouncing and reflecting against the edges of the frame. It gets pretty close to screensaver territory, and it's honestly really cool to see these kinds of animations so early. It's especially strange to think of them coming on physical film and not a CRT. I'm sure we all can think about a ball demo bouncing on the edge of a CRT, but this is on the edge of a film frame. That's just neat to me. The final piece to mention about these early animations is how mixed medium they are. Sure, it's all film, but there's an interesting mix of what's on the film. You get graphics and you get text. That on its own is cool, but you also get physical images. This part's kind of strange and only shows up in the shorter

test video. Basically, at one point, a slide starts talking about the fact that animation was produced using punched cards. Then an actual punch card appears in the corner of the screen. Then you see a hand flipping the card over. The effect here is simple. Nolten must have been doing something like a double exposure. The result is a fully analog image on the same frame as digitally generated data. It's obviously a way to quickly get a card on screen, but the implications here are neat. It's a mix of old and new that I kinda like. Then come the twin factors of cost and complexity.

The longer of the two videos was about 17 minutes. That's the actual released video that Nolson talks about in his piece with Filmmaker's Newsletter. He estimates that the entire animation took about 1,500 lines of code to produce, and cost around $600 per minute. So we're looking at just over $10,000 for that one film. That includes computer time and his salary, so it's a pretty good cost estimate. Knowlton also explains how his workflow was simplified thanks to automation. Since everything was just code, it was easy to repurpose parts of one animation for another.

To quote, if you go on from this film to do another film very much like it, but in somewhat more detail, say a second more detailed lesson in the same area, the next one comes much easier because much of the programming is already done. That is, I would reuse many of the subroutines from this film, so another film would be faster. In general, if you were to take any area and do a sequence of films along the same theme, dealing with the same objects or the same operations or both, the latter films in the series would tend to be new configurations of the same objects or sequences of the same operations, and the programming would be much faster. End quote.

Here, Knowlton is just doing what any good programmer has to do, finding ways to save yourself some work. You should find ways to skimp on work when you can get away with it without compromising your final product. Another benefit of this digital workflow was that Nolten could generate test prints of his films. This is, once again, a classic example of normal programming practice, just applied to a new medium. You think your code works, so you run it. Turns out you're wrong. You then adjust for any errors, debug it, add in new features, you know, the traditional workflow of iterating and modifying. But here, Nolten is, once again, just applying the programmer mindset to art. Of course, this wouldn't be much of an animation language if its only outputs were about, well, itself.

There was the video that describes L6, but that's still firmly in the documentation camp. You see, B-Flix did, in fact, get used for art. During the latter part of the 60s, Knowlton made the acquaintance of Stan Vanderbeek, an artist interested in experimental film. Together, they made a slate of movies using B-Flicks. There were eight films in all. I'll link probably on my Twitter feed to as many as I can find. It seems like at least two aren't preserved, or if they are, they aren't anywhere that's searchable. The remaining works, called Poem Field Numbers 1 through 6, mainly focus around text. The workflow went something like this initially. For the earliest collaborative films, Vanden Beek would write up a poem. Knowlton took the poem and

animated it using B-Flix, adding in psychedelic fades, transitions, and dissolves and other kinds of effects. Vanderbeek then took the film and added color using existing analog techniques. That's fine for a start, but the arrangement had to change to become more fruitful. Knowlton worked up a set of B-Flix macros for generating text and applying effects. This was, once again, a tool to streamline the process of generating films. Vanderbeek was doing a lot of text stuff, so Nolten was able to wrap up those functions for later use. Eventually, Vanderbeek, an artist, was able to create animations in Bflix all on his own. Knowlton was just around to provide debugging help. I think this is a fascinating point to linger on,

especially in the larger context of Knowlton's work. He was providing ways for artists to use a new medium, the computer. He had initially stumbled into this role by pure chance. Back during his work on perceptional collages, he had got the chance to present his 12-foot nude in an art show. The theme of the show was collaboration between programmers and artists. Knowlton and one of his colleagues, Leon Harmon, were slated to go to this art show together. Harmon had initially given Knowlton the idea

for the prank, so maybe he was the mastermind after all. Anyway, let's head to a problem. The duo were both programmers. From Knowlton's Portrait of the Artist, quote, one of us had to be an artist. So by the whim of a spin-launched coin, Leon became the artist and I remained a technologist. Pretense aside, so did he. I did not understand until ten years later that I had lost the toss, since artists, I was learning, were the perceptive predictors, the daring, flamboyant, flamboyant and revered analysts of the past, present, and future. The grand but sly commentators on human joy and sorrow. End quote. Nolten was perpetually working towards the role of artist. B-Flix was a big step towards that for him, in that sense at least. But it wasn't just a nice line item on his CV. This strange little

language provided a new tool, a new window of opportunity, a new way for art to be made. Alright, that brings us to the end of this episode. This also rounds out my discussion of digital art for the time being. Like I said, I didn't intend this to be back-to-back art episodes, but I got pulled into a strange path and just had to keep going. I think the crux of Knowlton's work, and really this dive into computerized art in general, is a bit of a twisting story. Computers were built as a way to go beyond the confines of our analog world. A way to automate mathematics and to create totally new ways to answer questions. As a result, us humans have been able to imagine all new kinds of questions to ask

and then answer most of them. But sometimes we twist back into the analog space. Sometimes we're just working on the edge of what's possible with computers. Or maybe it's just useful to fall back to analog methods. Bflix is a fun example of this twist. Visual art in the 60s was still very much an analog world. Films were still on physical reels, projected using mechanical devices. Animation was drawn by hand, or movies were recorded using an analog camera. B-Flix offered an alternative, but to do so, Knowlton had to twist up a computer enough that it could jump back over the analog divide. Doing so, he brought

all the benefits of the digital realm into filmmaking. Reusability, automation, higher order mathematics, all the good stuff that made computers exciting in the first place. I'd like to close things out with a reflection of this month's worth of episodes. Last time, we looked at the ILLIAC suite, a music composition written by a computer. In that, Hiller and Isaacson, the programmers behind the machine, faced a similar digital-to-analog problem. They needed a way to turn a digital composition stored as numbers into sound. Their solution was to notate the music for humans and have a human orchestra play this inhuman tune.

That's the same kind of twist. The Iliac Suite, like B-Flix, turned a computer back towards the analog era. It was able to apply the power of a digital machine to solving an analog problem. I think there's something interesting there. Computers don't have to be these isolated, number-crunching islands. Today, digital machines are multimedia powerhouses. The capability has been there from the start. It just took some time for this twist to become accessible and useful on a larger stage. Thanks for listening to Advent of Computing. I'll be back in two weeks time with another piece of computing's past. Hey, if you like the show, there are now a few ways you can support it. If you know someone else who'd like the show, then why not take a minute to share it with them?

You can also rate and review on Apple Podcasts. And if you want to be a superfan, then you can support the show directly through Advent of Computing merch or signing up as a patron on Patreon. Patrons get assorted benefits like early access to episodes, polls for the direction of the show, and bonus episodes. You can find links to everything on my website, adventofcomputing.com. If you have any comments or suggestions for a future episode, then go ahead and shoot me a tweet. I'm at Advent of Comp on Twitter, and I always love talking to people over there. And as always, have a great rest of your day.