Clarence Barlow's program AUTOBUSK is the result of decades of research. Originating out of compositional necessity, it incorporates many unique and novel music theoretical concepts (such as harmonicity and metriclarity) and compositional tools (such as scale rationalization) developed by the composer himself. To get a better idea of just what this program is and what it can do, I sat down with Professor Barlow in his office at UCSB to discuss it.
Mongoven: Hello, I'm composer Casey Mongoven I'm here at UCSB with Clarence Barlow. Thank you for agreeing to take part in this interview Professor Barlow.
Barlow: No problem.
Mongoven: Well why don't we go ahead and get started.
Mongoven: We are talking about your program and compositional tool AUTOBUSK. OK, I have a few questions prepared for you. What brought you to start writing AUTOBUSK in August of 1986?
Barlow: Yes, there is a little pre-history to that. In 1978 I began to develop software or, say, algorithms to generate variable tonality and variable metricism. Now all of that goes back to 1975, when I was travelling Turkey and had the idea to write a very big piano piece in which this would actually happen - very polyphonic, with variable ...
Mongoven: OK, so it was out of compositional necessity in a way that these ...
Barlow: Yes, exactly, so it started without me even knowing how I would do it. I just knew I needed to study tonality, I needed to study metricism, went through the literature, found that I couldn't find anything that I really needed for myself. So in '78 I developed the algorithms and implemented them in FORTRAN ...
Barlow: ... and developed my piece, wrote my piece. And that was performed in 1980, and I was invited then to IRCAM in Paris to install those algorithms on their computers, but the computers were so small. The one I was given had 25 kilobytes. And of those 25, eight were used for the sound synthesis. So it wasn't really much to go by, or to use, so I had to stop. But then in '86 ... '84 I bought my own computer, which had one complete megabyte of memory.
Mongoven: For that, at that time ...
Barlow: Yea, it was huge at that time ...
Mongoven: It was huge ...
Barlow: ... a hard disk of 10 megabytes. And I was commissioned to write a piece for the International Computer Music Conference in '86 in The Hague. It was in '84 that I was asked to do this. So in the summer of '86 I became a guest at the Institute STEIM in Amsterdam, and decided that would be my first project, so I landed there in August and started straight away to work on the software. Within three weeks I had the software more or less ready, I kept patching it, you know, fixing things the following weeks. But the first three weeks I wrote the software, the second three weeks I wrote the piece and ... it was performed in October '86. And from then till 2002 I kept expanding the progamme, changing things, and declared it finished in 2002 on the Atari.
Mongoven: Excellent, yea OK, you have already answered some of my questions, actually. But can you ... what kind of machine were you originally working on in '86?
Barlow: It was a custom-made machine, which cost me about $30,000, and it was ...
Mongoven: $30,000 dollars?
Mongoven: At that time?
Barlow: At that time. Made for me specially. Of course, these guys in the town Essen, very close to Cologne, they were making this type of computer, but I had to specify what I wanted and one of the things I wanted was a MIDI interface. So even before the Atari came up with its MIDI interface I had a computer with in-built MIDI.
Mongoven: So it was a custom MIDI interface which they had built for you.
Barlow: Right, yea.
Barlow: So, you know, '84 is when MIDI appeared and '86 is when I took possession - no I think it was '85 when I took possession of the computer, in February '85.
Mongoven: OK, excellent.
Barlow: And it was ... the processor was an 8186, so it was like the predecessor of the 286 which was better known and the 386 which finally became Pentium, and so on and so on ...
Mongoven: OK, that became the Pentium then ...
Barlow: Yea, but the ... I wasn't using any Microsoft software. It had its own, it had its own ... it had a CPM ...
Mongoven: I am sure a lot of our viewers would like that.
Barlow: CPM [Control Program for Microcomputers]
Mongoven: CPM? Those are my initials actually.
Barlow: Right, exactly ... exactly.
Mongoven: OK, excellent. Well what can AUTOBUSK do, Professor Barlow?
Barlow: AUTOBUSK can generate MIDI streams which in the normal case would be note-on and note-offs and you can remap them to get, you know, controller values, or pitch bend, whatever you'd like as well. You can do this, but basically it's note-on and note-offs in given scales and given meters. So let's say you give it the major scale and you give it, say 6/8. Then it'll generate a melody in 6/8 in the major scale, or in the chromatic scale, for instance. Now you can say "I want this music to become atonal", so you turn down parameter 8.
Mongoven: OK, which is ...
Barlow: The degree of tonality.
Mongoven: Degree of tonality?
Barlow: And if it is 0 it's atonal, and if it's 12, that's the maximum value for that parameter ...
Mongoven: And the degree of tonality is ... based, is represented by an algorithm for you, perhaps?
Barlow: It is based on the algorithm I developed in '78. Based on that.
Mongoven: OK, gotcha.
Barlow: So what I do is I take a scale, any scale - a microtonal scale is also possible - I then rationalize it using my own algorithms, my harmonic theory if you'd like to call it that.
Mongoven: Yea, why do you do that? That is one of my questions.
Barlow: Well, I wanted to understand how harmony works. And I found no textbooks which explained microtonality in terms of harmony. Hindemith had done a lot with the twelve tone system. But, uh, that didn't go far enough as far as I could see in any case. And to be able to use ... to be able to fathom the harmonicity or the harmony of any scale whatsoever, microtonal or not, I mean that meant ... it was a tall order. So I had to do a lot of research and I developed these algorithms for that. It worked very well, because when I put in a known scale into my algorithms - to rationalize them - you know I put in the cent values; say, the chromatic scale would be 0, 100, 200, 300, 400 and so on cents.
Barlow: Out comes out of the programs in the rule, 1:1, 15:16, 8:9 ...
Mongoven: Exactly, which are very much the canonical ...
Barlow: I have tested it on Western scales and Indian scale, Chinese and Arabic scales, or Arabian I should say, Arabian scales, and they all worked. They came out to be the text book values.
Mongoven: Yes, I've seen some of those examples, very interesting stuff. OK, do you know of any other programs by other authors, which are ... which have a similar paradigm?
Barlow: Not really.
Mongoven: Not really.
Barlow: Could be my ignorance.
Mongoven: Well [laughs], probably not.
Barlow: Well I know there are people who like my programme. And there are people who actually have it on their websites.
Mongoven: Ah, OK. That's true it is available in the Internet, we should definitely note that.
Barlow: If you google AUTOBUSK, A-U-T-O-B-U-S-K, you'll find a lot of links to that. And these guys, they say it's unique.
Mongoven: Excellent, and the manual is available online too, isn't it.
Barlow: Yes, exactly.
Mongoven: OK. So now I'm going to get a little more detailed here, if you don't mind ...
Barlow: No problem.
Mongoven: What are the pre-processors in AUTOBUSK?
Barlow: Ah [laughs]. These are the programs ...
Mongoven: PREPROCs? I think.
Barlow: Yea, I abbreviated it PREPROC. Sounds a little bit like Beeblebrox or something, you know ...
Mongoven: Sure ...
Barlow: Douglas Adams
Barlow: Well, PREPROC means you compile your material. In other words you put in cent values for a scale, and you put in stratifications for a meter, and I'll explain what that is. Suppose you have a 12/16 meter, that's twelve pulses, but they are actually grouped in two groups of six. And each group of six is divided into two groups of three.
Mongoven: So that is your specification of that ...
Barlow: Yea, I call it 2 by 2 by 3, and that is the stratification of 12/16. And any of the meters I am inputting have to be the product of prime numbers.
Barlow: So that's the stratification, the order in which ... for instance, 3/4 on a 16th note level would be 3 by 2 by 2.
Barlow: But a 12/16 on a 16th note level would be 2 by 2 by 3. So any order of prime numbers, and I believe I can as many as 255 or ...
Mongoven: So you see that as, in a way, as the most compact representation of ...
Barlow: Yea, well it gives you the inner structure. I use multiplicative meters. Now if I use something which people would call an additive meter like a 7, that stands on its own. It's there, it's possible, but I use the prime number 7 then and it's usually 3, no wait a second ... 2 + 2 + 3. Usually a prime number would always end with a 3. And before the 3 you have an even number which is divided into equal numbers of 2s. So that's the way I do it. I can take any prime number and make that either into a meter by itself or into the factor of the stratification of the meter. If you'd like you can have a 23 by 7 meter ...
Mongoven: Sure, get creative.
Barlow: Yea, and that could be then compiled by the PREPROC programs.
Mongoven: Exactly, and have you written works that use such complex ...
Barlow: Not that complex, but certainly things like maybe 7 by 3 by 2. Something like that.
Mongoven: OK, definitely, I can imagine that in your works [laughs]. OK, I actually already asked the ... OK, what does the .HRM file do?
Barlow: The .HRM file is the one that compiles the cent file. So I have a file with the extension .CTS, frowned upon on the Mac and on the PC, cause you're not supposed to have unusual extensions. But I have the file, it's a text file, a regular text file with a .CTS extension, I put that into the HRM program and the HRM, as you can imagine, is an abbreviation for harmony, but actually I call it Harmonic Rationalisation Measures.
Mongoven: Can you explain that a little bit?
Barlow: That's where the cent values go in and the ratios come out. So you have to put in a number of constraints. Constraints are, for instance, how tolerant do you want the tuning to be. So you, suppose you take a chromatic scale and you're extremely tolerant, then even the tritone could be regarded as a fifth. So you've got two versions ...
Barlow: But if you make it very intolerant it could be that you don't get a solution for a certain degree of the scale.
Mongoven: OK, where do you set these tolerances, for example?
Barlow: They're all in the program.
Mongoven: They're all in the program?
Barlow: Yea, so you set the ... one of the parameters is the ... what I call the nominal tolerance, because it has something to do with the variance of a Gaussian distribution curve. And I apply these Gaussian curves to each degree of the scale. And the width of the curve, you might say, is proportional to the tolerance.
Barlow: That's one thing. Then I have a thing called the minimum harmonicity. Everything is based on a vocabulary, which I have predefined. The one I usually use goes over eight octaves and contains a total of 18,000 intervals, and these intervals are all there to be looked at, so if the program is trying to tune a certain note, it will look in the neighborhood of that note and see all the intervals which are the strongest, and that's the third theorem - the number of alternative tunings that I want to use. So if I'm looking at, say, the major scale and I say two alternative tunings, then I might take for the perfect ... let's take the major third. I might take the Pythagorean third, which is 64:81, or I might take the overtone third, the just third - they're both just anyway - 4, 4:5.
Mongoven: OK, so once you have generated the possibilities, you can also mix and match so to speak?
Barlow: Yea, they're all in that file, it's called .JST, the extension is .JST. And in that file you have this whole vocabulary of intervals and HRM looks at the .JST and it looks at the .CTS file and gives you a rationalisation of the scale. Changing the constraints means you can get quite different tunings of the same scale.
Mongoven: OK, excellent.
Barlow: OK. And now you're going to ask me about the .IDP?
Mongoven: Oh, I wasn't going to get there yet, the IDP, but why don't you discuss that since I don't have that ...
Barlow: Well that's the other PREPROC programme, the other, you know, main one, and that is Indispensability Determination Programme.
Mongoven: And what is that?
Barlow: Now the indispensability is the, is the degree of importance of a pulse. Suppose I take 6/8.
Barlow: Now, if I try to dilute that, I would start off with
Mongoven: OK, in terms of which pulses are inside the meter.
Barlow: Exactly, I took away the least important ones - in other words the most dispensable, or the least indispensable - and the indispensability numbers range from 0 to Nó1, where N is the number of pulses.
Mongoven: Yea, that would make sense.
Barlow: So 0 to 5 in the case of 6/8. If I am taking the 8th note.
Mongoven: Sure. OK, excellent, so that is what the IDP does. What does that stand for again?
Barlow: Indispensability Determination Programme.
Mongoven: OK, excellent.
Barlow: But of course you can see, IDP is in the word indispensability.
Mongoven: Oh, that's nice too isn't it?
Barlow: So that's the main reason why I abbreviate, and find a result, or should we say find the solution to the acronym.
Mongoven: Oh, excellent, exactly.
Barlow: The same with HRM.
Mongoven: That's a talent of yours isn't it?
Barlow: Or some people call it a curse.
Mongoven: Or a curse [laughs], exactly. OK, why don't you describe the twelve parameters in AUTOBUSK a little bit.
Mongoven: I don't know if you know the order of them.
Barlow: Yea, the parameter one is what I call the metric clarity, which is the degree of metricity you might say, or the metric field strength - going from ametric all the way to metric.
Barlow: And you can move back continuously. Parameter two would be the pulse length, meaning "how fast is this music?" And it's in units of microseconds ... sorry, milliseconds, and the maximum length I have allowed in the program is 255, means a quarter of a second approximately ... all the way down to one millisecond, but I never have tempi like that cause no computer is fast enough, but I have experienced 5 milliseconds and you start to hear the music coming out. So really you get quite a lot of notes, 200 notes a second is possible and MIDI can handle just about that much, not more. The third one would be event density, in other words "how many events do you have in unit time?"
Barlow: If it's zero it's certainly silent and if it's maximum, you will have every possible pulse in the given meter attacked. The fourth one would be event length, varying from one pulse for every note, I call that like staccato in regular speech, up to the maximum which could be 255 pulses (just because one byte can carry that many). So 255 pulses means definitely legato, unless you have a note that is even longer than that. Then it will cut off after 255. Parameter 5 is the melody scope, the amount by which the melody is allowed to jump in half steps.
Barlow: So I could make it, you know, 127 (maximum).
Mongoven: And then it could jump from the very lowest note to the very highest?
Mongoven: Exactly, and you can set that accordingly. OK.
Barlow: Right. And parameter six will be the key note, the tonic. So if I say middle C or I say treble C, I put it in MIDI values 60 and 72 - that's got the tonic. I don't believe in octave equivalence. So any note can be the tonic - even a note at the very top of the scale can be a tonic.
Mongoven: That's interesting, why don't you talk about that a little bit - you don't believe in octave equivalence.
Barlow: Well ...
Mongoven: Do you mean that as a more general statement about music, or ...
Barlow: Well some people thing because they have the same name they're the same note. You know, C and the next is C ...
Mongoven: Yea, I have thought about that myself before.
Barlow: And I say they are two different notes. You know, you have ratios 1:2, so if 1:2 is equivalent why isn't 2:3 almost equivalent. I mean, there are degrees of equivalence, but I don't believe in taking out the octave and saying "OK, you're really totally perfect and the other guys are not."
Barlow: So I have a value - for instance my harmonicity values - there is a value for the octave, there is a value for the fifth, the octave could be 100 percent and the prime could be infinity, and the fifth could be 27 percent. So they all have a finite value except the prime. But the octave is not equivalent ...
Mongoven: Yea ...
Barlow: ... in my system. Parameter seven is what I call chordal weight - the weight of a chord. In other words, every event in every stream - AUTOBUSK has a maximum of three streams at one time, but you can of course daisy-chain a lot of computers, so that you could have three, six, nine, twelve voices at the same time if you want ...
Barlow: ... and they could all run in synch, but one particular AUTOBUSK program would run three streams, and each stream can have up to three notes, or event, that means three notes coming in simultaneously getting cut off simultaneously ... I call that monochrony.
Mongoven: Let me get this right, you have three streams that can play ... they are monophonic actually.
Barlow: Each of them is monochronic in a sense.
Mongoven: OK, but you can play notes just after each other one millisecond apart.
Barlow: Because, three streams can have different tempi. They can have totally different meters, totally different ...
Mongoven: Exactly, they're independent.
Barlow: Yea, they're independent. The three meters ... the three streams are totally independent, but each stream has one stream of time events ...
Barlow: ... so it's monochronous, and you can have a maximum of three notes coming in at one time, that's the chordal weight, parameter seven.
Barlow: Parameters eight is the degree of tonality, I call it toniclarity, if you'd like, or tonicality. And so if it's 0 it's atonal music, as far as the scale allows it to be atonal - if it's a pentatonic scale, all the notes would be equally probable at that level, at 0. It wouldn't sound atonal to the ear, because the pentatonic scale has an intrinsic tonality. But the chromatic scale definitely would - you give all the twelve notes equal probability of 8.3 percent and then it becomes atonal. When you raise it to the maximum value it becomes tonal; so the strong notes become more frequent and weak notes less frequent, and the function also on the weak pulses is more than on the strong pulses, which means that you have passing notes, leading notes on weak notes, you know, notes which are not as harmonic as the tonic and the fifth or whatever.
Barlow: And parameter 9 would be the, the pitch range ... not range, I'm sorry, the pitch register. So in other words ...
Mongoven: The register the melody is allowed to encompass?
Barlow: Exactly, you have pitch ... parameter 10 is the pitch range, and this is a pitch window which is centred on parameter 9. So you could have something like, let's say, moving within an octave or maybe a tritone or a fifth, very high up in the register ...
Mongoven: Centered on parameter 9 which is the tonal center or?
Barlow: The tonal center, the height ... not the tonic itself, so you can have the tonic even outside the window that's being played in. So parameter 9 is where the center of all the activity is - in pitch - parameter 10 is the width of that window on two sides of that center, which is parameter 9. And parameter 11 is the dynamic level, which is just plain and simple velocity.
Barlow: So if you set it to any value, you'll just get all notes at that velocity ... if it weren't for parameter 12, which was entered rather late. Parameter 12 is what I call the dynamic attenuation. So you specify how many plus or minus values of velocity you can have around parameter 11. It's a bit like parameter 9 and 10, the way they're related. 9 being the center or pitch and 10 being the range, so 11 and 12 are the central dynamic, and the range around it. So this attenuation works in such a way that if the meter is strong - that's parameter 1 - you will get strong attacks on the strong pulses, and weaker attacks on the weak pulses. But if you make parameter 1 zero, that means ametric, then it becomes random, and random pulses get attacked strongly and weakly. These are the twelve parameters.
Mongoven: Excellent. Excellent explanation, OK.
Barlow: Thank you.
Mongoven: Now why don't we move on to the .PRK score input file. What is that?
Barlow: OK, the .PRK is actually a compressed binary version of a .PRM file, so the .PRM file is what I would ...
Mongoven: So the better question might be "what is the .PRM file?"
Barlow: Exactly, the .PRM file is a text file containing six, if I remember right, six elements in every line.
Mongoven: OK, it's your own format?
Barlow: My own format, exactly. It again comes from parameter, but I'll now call it PRM, meaning Parameters, Routes and Material.
Mongoven: Wow, another creative one, OK, excellent.
Barlow: Another acronym.
Mongoven: Yea, another acronym [laughs].
Barlow: Because the routes - or route one might say in America - and so ...
Mongoven: Routes? I prefer routes.
Barlow: Routes, not roots with double-o, but O-U-T.
Mongoven: Ah, yes [laughs].
Barlow: So routes meaning "where are you sending the stuff?", like MIDI, for instance, a MIDI channel, for instance.
Barlow: Or, "is this going to be a note on or is it going to be a controller value?" These are all the routes. Then you have the material which is scales, meters and other information. So all three are contained in the .PRM file. Parameters, routes and material. And every line has five elements - I think five or six - let's count them and I'll tell you. So, the first two are time. Now I didn't use floating point values because in those days, floating point took long to read and to process, so I simply wrote them in seconds and milliseconds.
Mongoven: Practically ...
Barlow: Yea, so you could write any number of seconds up to 32,767, and the milliseconds, of course, went from 0 to 999.
Barlow: Then the next parameter was the track, or the stream ...
Mongoven: So left, middle or right.
Barlow: Left, middle or right, exactly. So you could have three values and I write them as L, M or R. And the next one after that would be the, let me get this right, I'm not confusing with my .MDK format. The next one would be which parameter.
Mongoven: OK, 1 through 12?
Barlow: Exactly, it could also be S for scale M for meter. Things like that.
Barlow: And the next one after that would be the value, so I think I have counted five.
Mongoven: The value of that parameter to be set at that moment.
Barlow: ... at that moment in time. So you have all these ...
Mongoven: So it is ... it does go from top to bottom in the way that some other programming languages like Csound might work, for example.
Barlow: Yea, all the events are time-tagged. And I have a program specially go through a file, a .PRM file, to make sure that through concatenation or through merging of two different files I didn't get time tags mixed up. This program goes through and makes sure all the time-tags are in the right order.
Barlow: I they can start even with a negative value, if you want - because I remember doing a piece where I started at minus 10 seconds, then I went on stage - and the computer was offstage - so I needed those 10 seconds to get on stage to be able to sit at the piano, the player-piano, and then the piano started to play.
Mongoven: Is that the Beethoven Variazioni?
Barlow: Yea, Variazioni based on Beethoven's Opus 11 ... 111.
Barlow: And ... yea so those five elements are the elements of a .PRM file, but because I don't like loading files into memory and then saying "oh I don't want this I want another one" and you know we're talking about '86 and those years, it would take a while to read a file and store it. So I decided to have the file read on the fly, which meant that when I was satisfied with a .PRM file ...
Mongoven: You needed to compile it in binary.
Barlow: I compiled it into binary, into .PRK, which was read off the disk while the computer was composing.
Mongoven: Real-time, so to speak.
Barlow: Real-time, real-time disk reading and playing - and storing, if you want to store this information in a MIDI file, then it could also read and store at the same time ... so for an Atari it was pretty efficient.
Mongoven: Definitely. OK. Why don't you discuss a little bit the facilities located on the lower right hand side, such as FUSE, for example, or FILL.
Barlow: OK, those are what I call the PRMPROC programmes.
Barlow: So they're parameter ... PRM processors, because what they do is they take a .PRM file, or two or three, and operate on them. Now FUSE, for instance, is two different .PRMs which are merged to form one stream of time ... to one .PRM file. Then there would be VARY, which does things like accelerations and decelerations.
Mongoven: OK, so you can input a file and it will accelerate the ...
Barlow: Yea, I could tell it for instance "now I want the result to be half as long in time, to start at the given tempo at the beginning but to end at, say, four times the tempo ... or five times the tempo.
Mongoven: So all these take an input and perform a function on it, and sometimes there is more than one input I imagine.
Barlow: Yea, like for instance FUSE has more than one input - a maximum of 16 at one time. I can fuse 16 .PRMs at one time. Not because it couldn't manage more, but because they fit nicely on the Atari screen, and so that was it.
Mongoven: OK [laughs]. No, the interface is wonderful I have to say. It is very well designed.
Barlow: And then another interesting one would be PART, which is the opposite of FUSE. So I set certain criteria according to which the programme PART ...
Barlow: Yea, it splits it into two .PRMs, one of them with the things I want - and so I call them the X-file ...
Mongoven: So you have criteria, basically you are specifying what you want to ...
Barlow: Yea, he extracted files go to the X-file, nothing to do with ...
Mongoven: X-file, yea that was before that time.
Barlow: Yea, that was long before. And the other one is called the R-file. So it splits it into the X and the R for the remaining file. And then if I merge the two again with FUSE I get the original file back. But then I can do operations on the X-file, on the R-file as I care. That would be PART, for instance. Then ... let's name one more, FUSE ...
Mongoven: FUSE, we had FUSE didn't we?
Barlow: No, I'm sorry, FUSE we did. FILL.
Barlow: FILL is an interesting because out of AUTOBUSK, I can store what I call a flash. I have a term, which is again typical of me, I sometimes call it flash and I sometimes call if flush.
Mongoven: Actually that was my next question.
Barlow: Ah-ha! I am preempting you.
Mongoven: You are. Excellent.
Barlow: So flash is if I flash something to memory - internal memory of the computer. Which means all of the parameters, all of the materials, the entire configuration is flashed to memory and kept there, and I can recall it and use it again.
Mongoven: And recalling it is a flush? Is that correct or not?
Barlow: No, flushing is flushing the flash to disk.
Mongoven: Flushing the ... so it's the act of saving a flash?
Barlow: Yea, right. If I want to save in the programme there are a total of 0 to 99 possible flashes. 0 is the default. And if I want to add any to the memory, and then go from 1, 2, 3 ... then I can delete any of these at any time, even in the middle and the orders adjust to the top flash which happens to be any number up to 99. And I can then, by using the right mouse click on the flash button, I flush it to disk. It comes out in .PRM format. But it's only one time window because everything is marked 0 seconds 0 milliseconds. And all the parameters and materials are all in that. So now I could take two of these ... now suppose ... what I have done is I did a demo which I called Feld-Cage, so I imitated the music of Feldman, through AUTOBUSK, and flashed that. Then I imitated the music of Cage, as in Atlas Eclipticalis let's say, and then I did a FILL between the two, an interpolation, so I was able to start sounding like Feldman, with all those - you know, soft and long chords and everything - and gradually move to very far ... displaced single notes of quite different dynamics.
Barlow: And of different durations. Things like that. So I was able to move very smoothly from one to the other, and that was done with FILL.
Barlow: Or another example, I once gave a lecture on AUTOBUSK in the city of Mainz, which is near Frankfurt - another city near Frankfurt is Darmstadt. Now Mainz is the center of one of Germany's big Mardi Gras - carnival - and they have all this march music; and in Darmstadt you have the school of Avant Garde from the time of Stockhausen, the young Stockhausen ... sounds like young Frankenstein ...
Barlow: So, from that time it has this very strange plink-plonk music. So I did AUTOBUSK again, I made march music and I made plink-plonk music and then I interpolated with FILL.
Mongoven: ... interpolated between the two styles.
Mongoven: Over how long a period does this ...
Barlow: You could do it in 10 seconds, but you could do it in a minute, you could do it in 5 minutes, anything you'd like.
Mongoven: And in your case, what were you doing?
Barlow: Well I took a minute, I didn't want to take too much time from the lecture.
Barlow: So I told those guys "look we're going 30 kilometers" - that's the distance between Mainz and Darmstadt - "30 kilometers in 1 minute." And you go from this march music all the way to the plink-plonk music.
Mongoven: Excellent. OK. You indicate in the manual that the MIDI input facilities are complicated in AUTOBUSK.
Barlow: Yes ... yea, they are very complicated.
Mongoven: Could you briefly describe them?
Barlow: OK, I'll try. Well for one thing there is the MIDI input monitor, so it shows you ... you can put in 16 MIDI channels - there aren't any more than that in any case - but in each channel you could use different types of MIDI, you could use note-ons, note-offs, you could use controller values, pitch bends anything you'd like. So when I use my fader box connected to AUTOBUSK, I'm using controller values. So I have one column for controller, the one column for each status byte, and one row for each MIDI channel. So there will be 16 that way and 8 this way.
Mongoven: OK, that's in the center of the interface.
Barlow: That's the input monitor. And then you see what I call the relevant byte coming in. I decided that one of the two data bytes coming in - sometimes you only have one like in programme change - but if you have pitch, you know note-on, you have controller, you have two data bytes coming in, and I take one of these to be the more important one. Like in the case of pitch it will be the note and not the velocity.
Mongoven: OK, so there's a precedence there.
Barlow: Yea, and that one's displayed in the input monitor as a number, and that number in hex, it just goes up or down according to how you change your input; use a MIDI keyboard ...
Mongoven: In hexidecimal notation.
Barlow: Hexidecimal notation in that MIDI input box. Now what happens is, I can ... the little strip to the left of that box called the allocation column, if you'd like, and there I specify what type of MIDI is going to change what parameter. So suppose - let's take a simple case - I want to change the tonic of the music I'm playing. So I have a keyboard attached, let's say, so I write in that allocation thing that 9 - which is the status nibble for note-on - I say that 9 is going to be the important signal coming in for this parameter which would be parameter 6. Parameter 6 is the tonic. And then 9 would mean the note-on, that means any note I play on that keyboard is now going to change ...
Mongoven: Right, so you're mapping the different possible MIDI parameters to ...
Barlow: Right ...
Mongoven: That's one reason that it's probably complicated is because you map any MIDI parameter to any AUTOBUSK parameter and that would control that.
Barlow: Right, any type of MIDI, it could be any status byte, but you have to allocate it, and you have to allocate it to a constellation of parameters or a certain, like you could say left alone, or left and right, or left and middle, middle and right, left, middle and right ...
Barlow: You know, so ...
Mongoven: And they would be attributed to that channel or whatever.
Barlow: Right, and those two streams will then be affected.
Mongoven: So I can theoretically hook up this MIDI controller to it and change the metriclarity, for example, by changing my pitch, for example.
Barlow: Exactly right, any type of input MIDI ...
Mongoven: But you prefer ...
Barlow: I'm sorry, except system exclusive. I do have an F in there as well, but it's very complicated because if you use system exclusive, every company has a different code, so you're not going to be able to use that meaningfully. It's there, you could send in F and see what happens, but the other ones are actually more relevant.
Mongoven: What I was going to say, yea, is that you prefer to use a mixer to a MIDI controller, generally.
Barlow: Right, I have a 16 channel, MIDI channel mixer. The trouble is that I would really need three in order to do all the streams. But if I do the allocation correctly and I've also made back on a keyboard ... the ideal thing would be to have a MIDI mixer and a MIDI keyboard at the same time, because I can use the programme change buttons to change the allocation.
Mongoven: Yes, I understand, and you don't have those on your mixer?
Barlow: Not on the mixer, so you could change them on the machine, and the keyboard is useful for certain things like pitch ...
Barlow: Yea, like if you want the music to go high in pitch like parameter 9, then you play a high note and it all goes up, for instance, or do a kind of glissando.
Mongoven: Excellent. OK. Can you describe the various types of mouse cursors that you developed for AUTOBUSK.
Barlow: Oh, right. Yea, if I remember right there are five. And these are to remind you of what you can do and where the mouse is active.
Mongoven: And is it true that I can ... if I scroll with the mouse that it might change? To indicate what its function might be?
Barlow: Yea, not scrolling. There's the right and the left mouse buttons. So we're not talking about the Mac.
Mongoven: Right, well I use a two button mouse with my ... Mac sometimes [laughs].
Barlow: Well, yea, so that's it. So the left would, for instance if you are in the middle - what I call the PRM box - with all the parameters and meters, sorry materials and routes. If you are in the middle of that box, you suddenly see this plus minus mouse becoming active and it looks like a square with plus and minus at the top, the minus on the top left and the plus on the top right, which indicate that the minus would decrease the parameter value or the scale value or whatever, and vice versa. Then there is another one-click mouse, which is a kind of open circle, and it only becomes active in certain parts, like the buttons at the top left. And if you move the mouse to that place, this mouse becomes active. Let's talk about the inactive mouse, now the inactive mouse is where you can see nothing is going to happen. It's kind of like a square block - looks pretty dead, doesn't do much. But if you move over to the place where the one-click mouse becomes active, suddenly you get this mouse with an open circle in the middle ...
Barlow: ... and you are allowed to click once on that, if you keep the mouse depressed it will not act again, so there would be no flipping back and forth. You press it once, and in order to reactivate that you have to leave that area and re-enter it again, and then it's again active. So you can ... it's a kind of safeguard that you don't press it too hard while you're concentrating on something else.
Barlow: So you just simply set something, and you move away. That's another mouse. Another mouse would be the latch-on mouse. For instance, if you're in a box like the remap box, where you can say "note-ons now in the future are going to be, say a controller value" or whatever. So this only latches on to the places where the mouse has any effect. So you can't position the mouse at all between two places, you can either latch onto that or latch on to that and then click it. So that's the latch-on mouse, so ... and then there is the busy mouse.
Mongoven: Which is pretty much self-explanatory I would imagine?
Barlow: Right, it just kind of has a kind of AUTOBUSK logo appearing - usually it's not needed because it's very, very quick - so the mouse just turns into that and turns back again.
Mongoven: OK. Excellent, is that it with the mouse cursors? Or are there any more?
Barlow: Yea, that's it I think that was five.
Barlow: I think I mentioned five.
Mongoven: Excellent, how many pieces have you written with AUTOBUSK, or can you even say?
Barlow: That's a good question, I would say a total of about eight. That's to say never, except on rare occasions, a complete piece. Variazioni was a complete piece done with AUTOBUSK, so is otodeblu, so is Pandora which is one movement of Orchideæ Ordinariæ. So I have often written a bit of music, just a short bit, like for instance in my piece Septima de facto, there is a saxophone solo near the end, and that's done by AUTOBUSK. The rest of it's not. So parts of pieces, and starting in '86, and the last time I think I did it was Septima de facto (2006), so I've been using AUTOBUSK now for 20 years already, but not every piece is with AUTOBUSK, so I've done a total of maybe eight to ten pieces.
Mongoven: And you develop a host of other programs that you compose with as well.
Barlow: Yea, right. Usually, it's the rule that if I try to compose a piece by hand - and I have - and I find that I have to resort to the computer again, it'll be a completely custom made programme for that piece.
Mongoven: Is that right?
Mongoven: OK, interesting.
Barlow: But I have written music purely by hand, that much [gestures a small amount], in recent years ...
Mongoven: Me neither [laughs].
Barlow: Yea we algorithmicists [laughs].
Mongoven: [laughing] Yea, exactly. Excellent. What would you consider your most important pieces using AUTOBUSK, perhaps the first piece you wrote with it?
Barlow: Yea, Variazioni definitely.
Barlow: ... movements of Orchideæ Ordinariæ, that piece is, I think, very important for me.
Mongoven: And that's, what is the ...
Barlow: The year?
Mongoven: When was it written and what was it for?
Barlow: It was written in '88 and it was for a very large orchestra - about 84 musicians. And it's a 40 minute piece.
Barlow: So, that's that. And, well ... other important pieces with AUTOBUSK, see I could name important pieces anyway like Im Januar am Nil was not written in AUTOBUSK, or Çogluotobüsisletmesi using the algorithms of AUTOBUSK.
Barlow: ... before AUTOBUSK was actually ...
Mongoven: Before, OK.
Barlow: Yea, eight years before.
Mongoven: Very interesting. OK ... could you describe the last piece you wrote with it?
Barlow: Septima de facto?
Mongoven: That was Septima de facto.
Barlow: Yea, just simply the saxophone solo. It just goes and ... it sounds somewhat, it sounds a little bit like, you know, rhythm and blues in a sense.
Mongoven: Didn't you use it in your piece that you wrote for the Bohlen-Pierce scale?
Barlow: Not AUTOBUSK.
Mongoven: Not AUTOBUSK?
Barlow: No, but I did use a multi-dimensional scaling map of my AUTOBUSK rationalizations.
Mongoven: You used the rationalizations from that program, OK ...
Barlow: Right, not the programme itself, but I used the HRM programme for that.
Barlow: Yea, I take HRM, I put in the scale, like the Bohlen-Pierce, enter it in cents, out come a bunch of ratios, and then I put the ratios into a multi-dimensional scaling programme which regards harmonic as very similar and inharmonic as very dissimilar. It makes the multi-dimensional scaling map, then I can see all the notes of the scale in different places, related notes close together, then I move in that map. That's how I composed that piece, and the most recent piece which is vinte e cinco anèis, which is going to be premiered next month.
Mongoven: Excellent, OK. Have other composers used AUTOBUSK in their music?
Barlow: As far as I know, I can remember some of my students in The Hague who made a piece of grunge music out of it.
Mongoven: Oh fantastic, really?
Barlow: And ... well, it wasn't anything I would have made, and that was great.
Barlow: I didn't keep a copy, I should have.
Mongoven: It probably wasn't expected.
Barlow: Yea, they wanted to play it to me and I went to my studio and they put it on, and I said "wow this is great."
Mongoven: And did it sound a lot like other grunge music?
Mongoven: Seattle kind of vibe?
Barlow: I couldn't place it exactly whether it's Seattle or Vancouver.
Mongoven: Or Vancouver [laughs], excellent. Excellent, OK, let's move on then ...
Barlow: You know, if I could interrupt just briefly, there may be students standing outside, I'll just tell them it's going to take a while and I'll come back ...
Mongoven: Definitely ...[CUT 15 seconds]
Mongoven: So I notice you created a lot of your own symbols in AUTOBUSK.
Mongoven: Could you describe some of them, for example, I know you have the left right symbols and you created basically symbols for every combination of left-middle, left-right, and everything like that. What are some of the other symbols?
Barlow: Yea, right, well the fonts themselves, I could see that on the Atari it was taking one millisecond to place every single normal Atari operating system character.
Mongoven: OK, so they had larger characters then?
Barlow: Yea, you could even make them small but it would take one millisecond, so if you wanted to write C#3, that's three milliseconds gone.
Mongoven: So you wanted to make it one character, for example, C#3.
Barlow: Yes, so I designed a matrix for every single character I could possibly use, so C#3 is matrix of 16X8 pixels, and that's stored in memory at the very beginning, and placing that takes one millisecond, so in other words it speeds up the writing of the characters ... of course with present day computers that's not an issue, but when I did it in '86 it was. So I definitely sped it up to three times the speed of, you know, updating the display.
Mongoven: Excellent, efficiency was very important at that time.
Barlow: Very important, both in time and space.
Mongoven: Definitely, OK. When did you complete the manual for AUTOBUSK?
Barlow: That was, I believe, 2000. Having done the programme, I added in a few little things in 2002, but in 2000 I declared ...
Mongoven: Was that at the request of other people, or did you decide to do it?
Barlow: No, I felt that if this programme is going to be out there somewhere, and people wanted to put it out on the Internet, and so I thought there should be a manual for it too.
Mongoven: OK, excellent. In retrospect 10 years later, is there anything you would have done differently in creating AUTOBUSK? Or any facilities you would have included which you didn't?
Barlow: In my algorithms there are a few things which I could have done differently, not AUTOBUSK itself the programme, but, for instance, in my harmonicity, if I take two candidates for a certain degree of a scale, or three or four, I just, you know, summarily say let's take the three best, but there could be an option of deciding ... you know, having a cut-off harmonicity, so that one degree of the scale would only have one candidate because all the others are too weak. That would be possible. Except that I'm kind of too exhausted to go and change that now.
Mongoven: Absolutely, I can ...
Barlow: That's one thing and another thing is I could have also weighted these degrees according to their harmonicity. But as I said I gave them all an equal chance.
Barlow: So, you know, like the Pythagorean major third would be maybe less in its weighting than the 4:5 maybe. I gave them the same weighting, except I'm not talking about the Gaussian bell weighting, I'm talking about the ... because that really does ... an interval which is further away from the place where it should be, like the major third is 400 cents, let's say ...
Barlow: Now I have two candidates, one is the 4:5, which is 386 cents, the other is the Pythagorean, it's 408 cents, and the 386 is going to be a little bit further away from the 400 ...
Mongoven: ... on the bell curve.
Barlow: ... on the bell curve. So it'll be depressed somewhat more by my bell weighting, but once that's done, it comes into the race with its full value.
Mongoven: OK, interesting. So that would be an example of something you'd might add.
Barlow: Yea, I might have done differently ...
Mongoven: There's always ... you can always add programs can't you?
Barlow: Yea, the great thing is the results of the scale are so borne out by the, as you said, canonical tunings of well known scales.
Barlow: So I'm quite happy to live with what I have.
Mongoven: Absolutely, definitely. And the works are definitely a testament to the power of the compositional tool.
Barlow: Yea, the music satisfies me, I never release a piece until I'm really happy with it.
Mongoven: Excellent, that's a good attitude [laughs].
Mongoven: OK, in closing I think it should be mentioned that AUTOBUSK is available for download like we said.
Mongoven: What do you think of the Atari emulators, could you say something about it?
Barlow: Well, unfortunately the Mac doesn't have any reasonable emulator.
Mongoven: OK, so we had some trouble getting that to work ourselves.
Barlow: Right, I haven't tried the Linux emulator.
Mongoven: In the future there might be some Mac emulators that work though.
Barlow: Yea, the trouble is the Atari is receding more and more into the distance, and you never know, people might ... you know a new generation of people would be born and grow up and never knew the Atari and won't have the need for it at all. So the PC has a very good one I can recommend it it's called STEEM, S-T-E-E-M. And that works pretty well, there are a few little things that go wrong, like when I run AUTOBUSK on a real Atari compared to an emulator - a couple of discrepancies here and there, things that don't work.
Mongoven: Could you give some examples, or ...
Barlow: Well ...
Mongoven: Do you mostly use ... do you use emulators now or do you still work with an Atari machine?
Barlow: No I use emulators, I even bought an Atari about three years ago, and I haven't had the time to install it.
Mongoven: OK [laughs]. There you go, so the emulators are definitely very useable even if there are a few glitches.
Barlow: Yea, definitely. The only reason why I would actually install the Atari that I bought is to read my ZIP drives that I - you know - stored a lot of material on. And they can't be read from a PC, or a Mac. So one day I'll do that, maybe next summer.
Mongoven: Excellent, sounds good. Well thank you very much for your time Professor Barlow.
Barlow: Well thank you Casey, my pleasure.
Mongoven: Have an excellent day.
Barlow: You too.