PARSA – uvuvu

The latest album by PARSA makes for some nice spectrograms. PARSA has previously made music with cellular automata (CODE147) and has recently collaborated with Ramtin Niazi (CLEANBOUNCE VARIATIONS) and with Beckton Alps2 as PARSALPS (Reductions). Here are some of spectrograms of uvuvu and a discussion we had about the music.

1 didone256hanning2

[Me:] First of all, how did you make this album? The track titles include references to sampling window functions, including the names and sizes of different types of window (‘hanning’, ‘blackman’; 64, 128, 256). Do the titles relate to the way that the tracks were made?
Window functions happen to be the basis of spectrograms. The window size determines whether the accuracy and resolution of the image is concentrated more towards time (with a short window) or frequency (with a long window). The different window types produce different kinds of analysis errors / visual artifacts. This is what makes the visible false frequency bands that run parallel to the actual frequency, like ripples or echoes. In the spectrograms of your uvuvu tracks, it makes some really nice patterns.

2 qqqq3_64hanning16

[PARSA:] The album is comprised of recordings I’d made while prototyping a sequencer in Unity. uvuvu was actually its working title. I would have it send MIDI off to Ableton Operator, or a Nord Drum 2 or a desktop Blofeld. The result of this endeavor was a sluggish sequencer, the realization that I was actually better off coding my ideas instead of dragging patch cables around with a mouse, and hours of recorded material which I abandoned for a year or two. I later on started using Cecilia5, and reached for this big pile of audio as the basic material. The source material is that, and all later processing was done in Cecilia, using the Vectral module. So each track title is: {source-file}{FFT-Size}{FFT-Envelope}{FFT-Overlaps}. Describing the settings of the module. Intentionally named so, so I could return and tweak things, because there were too many files. I did not know much about sampling window functions at the time, and I intentionally refrained from looking them up.

I do programming for a living and a big part of that to me is to know the ins and outs of what I’m working with. But when working on my own stuff, I need to NOT know something about what I’m working with, otherwise I’ll move on. Maybe that’s why everything I’ve released so far doesn’t sound polished, or complete or whatever. I record the process, not the product. So these settings were chosen just because I liked their effects on certain source material!

I recently dug up uvuvu in preparation for a talk I did at Tom Mudd’s class at the University of Edinburgh.

“4 chimes256hanning2 or my attempt at learning about Markov chains”

“8 mainline_rework. This was around the time that uvuvu worked offline and exported MIDI files”

Looking at these, I would do a lot of things differently if I wanted to start writing this thing now. This project failed pretty bad!

3 0015064hanning8

[Me:] Right, so the track titles relate directly to the parameters of a FFT vocoder. It’s definitely useful to use file names like that when experimenting, to keep track of things. It’s interesting that you’ve worked with Tom Mudd – I like his synthesis work. Do you often do that kind of talk, or get involved with teaching?

I think I know what you mean about not quite knowing what you’re working on. I’m also interested in the process as much, if not more than, the product. One idea that’s been useful for my own work is Philip Galanter’s definition of generative art (http://philipgalanter.com/downloads/ga2003_what_is_genart.pdf). Its defining element is that the artist gives away some amount of creative control over to a generative system. It is this element that often makes generative art unpredictable from the artist’s point of view when making it (usually only within certain carefully specified parameters) and that’s often part of the reason for using generative systems. The system could be a set of rules to follow, a physical mechanism, or code executed on a computer, but in all cases what makes it a generative system is that it does some of the creative work that would otherwise be done by the artist. In your work on this album, would it qualify as generative in terms of this particular definition?

Why do say it failed, and what would you do differently now?

4 chimes256hanning2

[PARSA:] I enjoy Tom’s music. He’s doing some crazy stuff with cool tech, can’t wait to hear more. We live in the same city and meet once in a while and talk about what we’re working on. He was kind enough to get me to talk about my approach in his class. I don’t have any real teaching experience, or formal education for that matter. Preparing for it however helped me realize a lot of things about my own work. Its title was “Zen an the Art of Making Mistakes”, actually (I know…). So I guess it’s a bridge to the next topic.

All the tracks are definitely generative. All produced by tiny systems with Markov chains + feedback as their prominent features, in this instance. I surely prefer listening to music over creating music, so generative systems that run with little interference from my end are perfect for me. Maybe what I’m trying to do is not so different from what a photographer or documentary maker does. I just show up and decide what to record. But I’m not sure about actual unpredictability in my work. Particularly when parameters can be/are (carefully) specified, in a digital environment. For instance: https://www.roulettephysics.com/russian-hackers-find-a-way-to-beat-rng-slots/ So, maybe it has to do with scope, or the magnitude of change? No idea! I’m not smart: I still have to look up simple sorting algorithms after 10 years of programming, or use a calculator for simple multiplications. But that’s why I’ve chosen to work this way. Because every mistake I make seems like a suggestion made not by “me”, and I could use a lot of that. If I were to rely on what I know, I’d do very little.

The software failed because it was providing a solution to a non-existent problem. I realized I didn’t need to create a generic tool at all. I was creating an environment in Unity that allowed me to build systems by putting together buildings blocks I’d have to write.
Which is to say, I was using the building blocks of a programming language (system) to create another system that would enable me to do so. So it was a sub-language defined on a sub-language that was built on top of another couple of languages. Much like how we go about making other things nowadays. :) That level of abstraction was completely unnecessary, so the current version is only a few hundred lines of C code that supports live-coding by hot-reloading libraries.

5 bev128blackman4_8

[Me:] Good stuff. Thanks for your responses – it’s been very interesting.

uvuvu is available via Bandcamp:

Advertisements
This entry was posted in Music, Visual and tagged , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.