Steve’s Stuff

Success! After trying so hard to get Pd to play long samples, I finally decided to learn some Reaktor programming. Reaktor is a modular synthesis environment from Native Instruments. It’s a lot like Pd, but it’s a lot easier to make interesting software instruments. For instance, if you want an array of wave forms to choose from, you just create an oscillator bank whereas in Pd you would need to calculate all of the different waves you want to use, leaving a lot of room for error and such. It’s particularly useful for things like filters and reverb. In Pd you have to design your own filters (lots of math involved), but in Reaktor, you can just drop in what you want.

Yeah, this makes it a lot easier, but that doesn’t make the results invalid - just efficient. I’ve used Pd plenty. I know I can build most of the things in Reaktor, but it takes so long and I don’t see the point when I have a better tool available. Pd is a great learning tool and using it allowed me to jump right into Reaktor without much trouble.

Anyway, the point is, Reaktor has a multi channel “tape player” that stores audio files of any size in memory and can play them back efficiently. Pd just never offered any good way to do this easily, so I’m switching mostly to Reaktor. When I say “easily” I mean, a way that I could figure out in three weeks. I’m sure plenty of people have done similar things in Pd, but they probably have double my programming experience or more. In the end, all that matters is that it works. No extra points for doing it the hard way.

This shows Reaktor’s Tape Player

This is the top-level Reaktor code

This is some lower level code. As you can see, it’s basically connecting modules like in Pd. At its most basic, it has all the same low-level objects as Pd, but it also has a great library of ready-made stuff.

The makers of GEM had the foresight to allow the user to deactivate the border (title and scroll bars), which is great. That still leaves the OS control bar at the top of the screen. In the off chance that anyone is reading this, here’s my workaround. I’m using a projector for this project, so I can tell my Mac that it’s a second display, as opposed to a mirrored display. This will give the projector its own desktop without a control bar.

To set this option . . .

Open System Preferences
Click the display icon
Click the “arrangement” tab
Unclick the “mirror displays” option

Easy.

I’m doing a bit of video work for J.C. Combs’ final percussion ensemble concert. He’s created a tribute to Harry Partch, one of the most prominent microtonal composers. Partch was a renegade free-thinker who broke the bonds of Western tonality and equal temperament (the common tuning practice of the West) by creating a unique 43-note scale and an array of original instruments. My task is to play some video clips from a Harry Partch documentary along with editing and a few other tasks. All the clips were preprocessed so by the time Pd is involved, it doesn’t have to do any stressful video work.

I’m used to using PDP and PiDiP, two Pd externals that are fairly decent at image-based processing of live video. They’re not so great with pre-recorded video. I may have just mentioned this in a previous blog post, but allow me to repeat how annoying it is that the software designers decided to only support some obscure Quicktime codec that is now long gone. PDP supports .avi, if I remember correctly. Huh. That’s funny. .avi is a Windows format, but PDP isn’t even ported to Windows. Who came up with that great idea?

Fortunately, GEM (Graphics Environment for Multimedia) is a much better Pd external complete with a little documentation and some tutorials. Building a video player was mostly a matter of looking through the help files, reading a couple tutorials, and putting it all together.

The first step is to download Pd-Extended. It’s got all the major Pd externals included. I’ve included my patch below, although you might as well just go through some of the help files to make your own.

As you can see from the Pd code below, everything is straightforward. The [gemwin] object creates the window and accepts a number of messages including dimensions, border on/off, cursor on/off, and rendering on/off. Make sure you send dimension and border messages before creating the window. It’s easiest to stop rendering while you’re not actively watching a video. I didn’t run into CPU problems, but you never know.

The [pix_film] object played my QT files without and problems. Just send it a message with the file name and path. You can go frame-by-frame, auto-play, and see the total number of frames in the movie. I added a gain control [pix_gain] so that I can do nice smooth fades. Finally, you supply the dimensions of the video output. It’s a little confusing because you create the GEM window, but then you also have to specify the size of the video output within the GEM window. It would be nice if GEM automatically scaled the window so that you could use an object like [rectangle 4 3] and it would keep the same aspect ratio without you having to figure out a size that’s close.

There are a few objects left over, so just ignore those. I should have just deleted them. I found GEM video playback to be very high quality, but easy on the processor. I recommend it for anyone wanting to play video in Pd.

This is not pretty, but it works. Here are the steps . . .

1 - a band opens file.aif
2 - after a 10ms second delay, readsf~ receives the bang
3 - file.aif plays
4 - after the initial bang, a 100ms delay is triggered and opens the same file.aif
5 - after the initial bang, a 56 second delay is triggered and begins playing the second instance of readsf~
6 - after the first instance of readsf~ finishes, it outputs a bang
7 - that bang is sent to a 100ms and 56 second delay and begins the cycle again

*UPDATE*

okay, so this doesn’t work with multiple audio files. Pd is unstable and crashes after a few cycles.

At Professor Harrison’s suggestion, I looked at Zexy (a Pd external) to see if it’s multi-track recorder object would be useful. I still run into the problem of having to rewind the object once it plays through the sample. The object looks interesting for multi-track recording and playback, but it’s not really any better than readsf~ for my purposes. It would be faster to simply rewind a file as opposed to re-opening it as readsf~ requires, but it’s not significant enough to forgive the following hassle . . .

The Zexy object uses the .RAW format, whatever the heck that is. I’ve never seen it before. It’s always frustrating to me that Pd always wants a screwy file format in order to work properly. Sure, it’s got a wave and aif player, but some of the objects need bizarre codecs that are long sense gone. How hard would it be to figure out something standard and stick with it?

I’m going to go with the dueling readsf~ files tomorrow. Hopefully that will behave as I intend. More on this later.

I started doing serious work on the Pd programming for my project. The goal was to build a software sample player and live performance patch to tie everything together. As it happens, Pd is not exactly built for this.

There are two objects to read audio files: readsf~ and soundfiler~. The former streams the audio from disk while the latter writes the audio file to a table that you can then scrub through. The idea is that there are some rumbling, drone sounds that occur while the installation is at rest. As people enter the installation space, the patch begins to react and the calm, peaceful samples give way to more activity.

Anytime you’re working with audio files, you’re pretty much streaming them from, if you’ve broken your HD into volumes, the fastest part of the disk. This is crucial for uninterrupted playback. Unfortunately, readsf~ doesn’t work well with looping. Pd requires you to re-open the file each time you want to play it and then send the object a “start” message. This introduces unacceptable delay on the order of seconds (!) - may not sound like a lot, but your ear will easily pick up on millisecond delays. Mine will anyway. It’s not even that I’m getting a little zipper noise - it’s flat out dropping out for a second or two.

I experimented running two instances of readsf~ so that the second gets cued up seconds before the first finishes in hopes of moving seamlessly between the two. This works a little, but not great. It reduces the delay to a few milliseconds, but there’s still the issue of zipper noise.

One possibility is to tweak this configuration, but it’s horrible programming and needlessly complex. As a last resort, I will try sizable fade-ins and fade-outs to give me some breathing room with the overlap. It’s not a huge deal because I’m not working musically in the temporal sense. There are no beats or pulses - just atmospheric ambience. If I DID want to add beats, this will not work at all.

Soundfiler~, as I said before, writes the audio files to a table. This is great for short loops. You connect a sawtooth wave to a tabread~ (table reading) object and it continually cycles through it. You can even go backwards or scrub through the waveform. The problem with this approach is that all the sound files eventually get stored in the patch. My 60-second samples that I want to loop each need a 2.5 meg graph to hold them. Once more than two of these are present, Pd starts behaving erratically. It becomes unstable to the point that it’s unusable.

A possibility for this method is to cut my samples - maybe to one 8th the size. Then they will loop fine, but they’ll also be fairly short and anyone who stands just beyond the installation will be able to notice the same sounds repeating over and over again. I could work with randomly alternating samples so that periodically, something changes, just infrequently enough to not be easily detectable.

So, I’ve got one object that’s good for streaming, but bad for looping; and one object that’s great for looping, but bad for reading. As the guy trying to remove soap scum from his shower with a tooth brush always says, “there’s got to be a better way!”