Below you will find the third installment of Jitter Recipe Collection. More snacks for the Patching Enthusiast! Stay tuned for new entries to your favorite cookbook, or browse earlier installments of the Jitter Recipe series: Part 1 and Part 2.

Download the Max 4.6 patches and the Max 5 patches for all the recipes below.

Recipe 26: VideoSynth3

General Principles

• Performing transformations on a 3D matrix
• Generating video-synthesis with audio signals
• Colorizing a grayscale video

Commentary

The mechanics of this patch are very similar to the RagingSwirl patch, applied to video processing instead of OpenGL geometry. In this example, we are actually distorting and manipulating a 3D matrix, but only viewing one slice of it. The jit.charmap is used to turn our 1-plane matrix into a full color image.

Ingredients

• jit.rota
• jit.poke~
• jit.matrix
• jit.charmap
• jit.noise
• jit.dimmap

Technique

Using the “bot” subpatch, our matrix is continuously drawn into with the jit.poke~ object.

This is then rotated across 2 different dimensions using a combination of jit.dimmap and jit.rota (see RagingSwirl).

Next, we take one 2D slice of the larger matrix for display using the “srcdim” messages.

This is then converted to a 4-plane matrix and colorized using jit.charmap. By using an upsampled color map, we are able to constrain the palette, and decide between a smooth, cloudy look or a flat, hard-edged look.

Recipe 27: Debris

General Principles

• Using the alpha channel to do complex blending effects
• Analyzing movement between frames
• Using feedback to maintain continuity.

Commentary

This demonstrates a way to generate an alpha-channel based on an analysis of the video. Here we use the amount of movement (difference) between consecutive frames, and then impose a threshold to decide what pixels will be visible. The effect resembles that of a degraded digital video signal, and can be used to generate all sorts of pixel debris.

Ingredients

• jit.qt.grab
• jit.rgb2luma
• jit.unpack
• jit.pack
• jit.matrix
• jit.op
• random

Technique

The most important aspect of the processing is the generation of an alpha mask. To do this we first convert our video stream to grayscale using jit.rgb2luma.

The matrix is then downsampled using random “dim” messages, generated by the random object.

This is then compared to the previous frame using jit.op @op absdiff to get the absolute difference between the two. Note that we are taking advantage of the trigger object to perform this slight of hand.

Once we have generated our difference map, we then use jit.op @op > to create a threshold. This means that it will turn on any pixel that has changed more than the threshold. This will then serve as our alpha mask, but passing it into the first inlet of the jit.pack object.

Once our alpha channel has been packed in with our live feed, this is then blended with our current image using jit.alphablend. The resulting image is then fed back to be blended with the next frame using a named matrix.

Recipe 28: SubTitle

General Principles

• Adding text to live video display
• Converting text to matrix format
• Imposing a specific rendering order

Commentary

I get a lot of questions about dealing with text in video patches. Whether you are using text as labels, titles, or subtitles, you will generally want it to be in the foreground. In order to do this successfully, while maintaining the transparency of the jit.gl.text2d’s bounding box, you must impose a drawing order.

Ingredients

• jit.gl.videoplane
• jit.str.fromsymbol
• jit.textfile
• jit.gl.text2d

Technique

The key thing to this patch is maintaining the render order. To do this, we turn the @automatic off for all of our gl.objects, and then use the trigger object to bang them in sequence.

Using the jit.str.fromsymbol object, we route the text output from the textfield and convert it to a jitter matrix for rendering single-line text.

The jit.textfile object is very useful for dealing with formatted text. Simply double-click the object to bring up a text editing window.

By turning on @blend_enable for the jit.gl.text2d object, we make sure that only the text itself is displayed.

To generate the shadowed text, we actually render the text twice - once in black, and then offset in white.

Recipe 29: Stutters

General Principles

• Generating timing effects with frame messages
• Quicktime movie playback and looping

Commentary

This example is a simple patch that demonstrates a way to generate looping effects with jit.qt.movie. This is very useful for those who are interested in working with looping videos, and creating realtime editing patches. With a little tweaking, this patch could serve as the basis for more complex playback procedures.

Ingredients

• jit.qt.movie
• accum
• jit.window

Technique

First, we need to set jit.qt.movie’s autostart attribute to be off, to prevent it from playing back the movie file automatically.

The key to understanding this patch is the use of the accum (as a counter) along with the modulo (%) operator. This allows us to count loops.

One tricky bit is the use of the route object to obtain the framecount of each movie loaded into the jit.qt.movie object. This sets the modulo size of the entire movie, which makes sure that we always send frame numbers that are within the range of actual frames in the movie.

When the stutter toggle is turned on, a shorter loop of numbers is generated that is added to the current frame number.

These numbers are then sent to jit.qt.movie using the “frame” message.

Recipe 30: SoundLump

General Principles

• Using audio input to generate geometry
• Using an environment map to create reflective surfaces
• Using matrix feedback to generate motion
• Using geometrical expressions to create shapes

Commentary

This patch takes an audio signal and generates a cascading, lumpy surface. Using some simple expressions, this surface is then distorted to create a pregnant lump. Environment mapping creates a liquid-like reflective surface.

Ingredients

• jit.catch~
• jit.gl.mesh
• jit.matrix
• jit.dimmap
• jit.gl.texture
• jit.qt.grab
• jit.expr

Technique

We take the vector of audio grabbed by jit.catch~ and render it to a single row of a matrix. This matrix is then stretched down slightly and fedback. This generates the cascading effect.

We then flip the matrix using jit.dimmap and use jit.expr to create the coordinates of our OpenGL shape.

By taking the sin of the x and y coordinates, we generate a rounded lump across the z-coordinates.

Once we have generated our figure using jit.gl.mesh, we use @tex_map 3 to apply our texture as an environment map. Lighting is enabled by turning on @auto_normals and @lighting_enable.

Our texture is generated using a similar technique to that used with our sound vector.

Recipe 31: Animator

General Principles

• Using the system clock for solid animation timing
• Animating parameters using breakpoints and pattr-family objects

Commentary

This example shows a good way to generate stable timing for automation parameters, despite the fluctuating framerates common to Jitter. By using the CPU clock, we ensure that the flow of the animation is steady regardless of framerate. It also shows a simple way to use autopattr and pattrstorage to manage many parameters at once.

Ingredients

• cpuclock
• jit.gl.mesh
• autopattr
• pattrstorage
• function

Technique

In order for autopattr to see our UI elements, we’ll need to name each of these objects. To do this,we simply select the object and hit Command+’ (mac) or Control+’(windows) and enter a name into the field.

Once we have set up our named UI objects, we can then store presets using the pattrstorage objects.

Because cpuclock counts the number of milliseconds since Max was opened, we will need to constrain the range of this output to be useful for us. To do this, we use a modulo (%) operator. The output is then fed into the function object, which outputs the value at that x-location of the curve.

This patch utilizes the handy interpolation function of pattrstorage, which allows you to recall in-between states by sending floating-point values.

This same technique could be applied to any number of parameters for any number of OpenGL or other Jitter objects for a complex animation setup.

Recipe 32: Hold Still

General Principles

• Using frame-differencing to detect movement
• Using video sensing to control sound synthesis

Commentary

One of the most straightforward ways to do video sensing with Jitter is to perform frame-differencing, which gives you a reading of the amount of movement. Using a couple of basic Jitter objects, we can map the amount of motion in a scene to a variety of synthesis parameters.

Ingredients

• jit.qt.grab
• jit.op
• jit.rgb2luma
• jit.slide
• jit.3m

Technique

First, we convert our video stream to single-plane using jit.rgb2luma. We do this for simplicity. You could also try performing these calculations with all of the individual color channels for more complexity.

To get the difference between consecutive frames, we use jit.op @op absdiff. This will show us the amount of movement between frames. We then use a jit.op to do apply a threshold. This will give us a binary image.

This image is then fed through jit.slide to remove flickering and smooth out the data flow.

The jit.3m gives the mean value of all of the cells in a matrix. If you remember your arithmetic, you will know that the mean is derived by adding all elements together and then dividing by the number of elements. We take the inverse approach to calculate the total number of white pixels in our image.

This is done by first multiplying the mean output by 327,200, which is the total number of pixels in a 640×480 matrix. Since the value of white in char data is 255, we must then divide by 255 to get the number of white pixels.

Once we have this number calculated, we can use it to drive the synthesis parameters of our audio stage.

Recipe 33: Fast Cuts

General Principles

• Loading a media folder for easy switching
• Creating automated real-time editing
• Tempo Sync

Commentary

This basic example provides the basic structure for creating a dynamic movie-clip playing VJ-style patch. In addition to providing a UI for media management, it also shows a simple way to tap out a sync tempo for timed changes. Add some compositing effects and you’ll be ready for the clubs.

Ingredients

• ubumenu
• dropfile
• jit.qt.movie
• sync~

Technique

First, we’ll start with our file loading mechanism. For convenience, we are using the dropfile object, which allows us to simply drop a folder with our media files, and it kindly outputs the file path for us to use elsewhere.

In order for the file path to have any effect, we have turned on the “autopopulate” attribute of our ubumenu. Now, if we send a “prefix …” message to ubumenu, it will automatically load the names of our files for later use.

One tricky thing we are doing is to use the dump output of ubumenu to give us the number of items we’ve populated it with and use that to set the range of our random object.

A similar trick is used to get the number of frames in each movie. Inside the “pick_a_start_frame” subpatch, you will see that everytime we read a clip, the “getframecount” message is triggered. This causes the jit.qt.movie object to report the number of frames, which is then used to set the range of a random object. All these messages are sent to the proper place by using the route object. This is how we get each movie to start at a random point in the clip.

For our tempo-sync module, we use the beat-following feature of the sync~ object. This tracks the interval between bangs and reports the BPM as well as generating a signal ramp and midiclock tick. We use the midiclock output to drive our fast cuts. Since midiclock counts 24 ticks for every beat, we use a counter->select combo to slow things down a bit.

Recipe 34: Alpha Toast

General Principles

• Video Compositing
• Generating an Alpha Channel for blending
• Using Video Input

Commentary

This patch is an homage to the first generation Video Toaster, which featured a number of snazzy transitional animations. For some reason, all I can remember now is the tennis player and the star wipe. AlphaToast uses the luminance of our live video input to generate an alpha channel for blending two movie sources. The results of this can be surprisingly complex and interesting.

Ingredients

• jit.alphablend
• jit.rgb2luma
• jit.qt.movie
• jit.qt.grab
• jit.unpack,jit.pack

Technique

To generate our alpha channel, we convert the output of jit.qt.grab to black/white by using the jit.rgb2luma object.

This 1-plane matrix is then scaled and offset using the jit.op object before packing it into the first plane of our jit.qt.movie output. This effectively gives our movie an alpha channel to use for blending.

The 2 video sources are then sent to jit.alphablend to be combined together. Try looking around for some hi contrast objects to play with. A flashlight can be quite useful for creating blending effects.

Recipe 35: Paramination

General Principles

• Using a matrix to store control data
• Interpolating control presets using common Jitter objects
• Using Jitter to control audio synthesis

Commentary

Managing control data can easily become a pet obsession for Max-users, especially once they’ve tackled the big obstacles of understanding digital audio and video processing. While there are a number of handy pattr-family objects to manage presets and such, I wanted to explore a different way of managing and interpolating presets using the Jitter matrix. One of the great benefits of this approach is being able to take advantage of all of the great generators and manipulators of data at your disposal. It is also a very efficient way of generating random parameters. This patch demonstrates the basic mechanics required to make this happen.

Ingredients

• jit.matrix
• jit.submatrix
• jit.fill
• jit.slide
• jit.iter
• jit.dimmap
• jit.noise

Technique

The list output of the multislider is converted to a matrix column using jit.fill. This column represents a single preset.

By using the “dstdim” messages to jit.matrix, we place each stored preset in a column of the matrix called “setbank”. This creates our bank of presets that will be used by our playback section on the right.

To access a specific preset-column, we use jit.submatrix, and use the offset attribute to define which column we will use.

The jit.dimmap converts the vertical column to a horizontal row. This is purely for visual feedback and offers no functional advantage.

The output is then sent to jit.slide, which performs temporal interpolation. This gives the effect of our presets slowly changing over time.

This preset matrix is then split up into individual values using jit.iter. Since jit.iter gives the cell-coordinate from its center outlet, this can be used as the index for each cell value. By packing the value and index into a list (and then reversing that list), it is now in a format that is easily managed by route.

Each cell value is sent to the appropriate output of route, and then used to drive the parameters of a synthesis engine.

Try using jit.bfg instead of jit.noise to generate randomness, or jit.xfade (or any compositing effect) to transition between different presets.

Recipe 36: TinyVideo

General Principles

• Using jit.expr to generate geometry data
• Performing texture animation
• Making animated sprites
• Using jit.op to do iterative process loops

Commentary

This recipe shows how to load a single texture with a bunch of frames, and then use texture coordinates to animate the texture. This in itself is a pretty handy technique, but I decided to add a bit of extra spice by also including a way to independently animate 100 textured-quads using only one texture and one OpenGL object.

Ingredients

• jit.expr
• jit.op
• jit.gl.texture
• jit.gl.mesh
• jit.matrix

Technique

We first need to collect some frames into our texture to be animated. In this case, we use jit.qt.grab, but any video source can be substituted here. This is done by sending srcdim messages to a jit.matrix object, which is big enough to fit 100 frames of 160×120 video.

Now that we have a jit.gl.texture with 100 frames of video loaded into it, we need to come up with some geometry to throw it onto. In this case, we’ll be using jit.expr to create a bunch of quads, or 4-point shapes to texture. You’ll find the magic inside the the gen_quads subpatch.

You may have noticed that the jit.matrix objects in here are 40×10 rather than 10×10. This we have done in order to make room for the 4 vertices that make up each quad. You may also note that we have switched to a 5-plane matrix. This is so that we can make use of the texture coordinates that we’ll be generating later.

To generate the quad geometry, we use jit.expr to fill a matrix using an expression that loops over 4 cells horizontally. This expression creates a rectangular set of points, and sets generic texture coordinates for each point. This filled matrix is then added to our input matrix to create a quad at each location defined in the input.

So far we’ve got a whole bunch of quads and a single texture, which is probably not very interesting. To get this thing moving, we need to create a way to loop the texture coordinates in a way that scrubs through our grid of frames in the texture. Have a look inside the animate_frames patch. The method we’ve used here makes use of modulo-arithmetic to loop the values in a 10×10 matrix from 0-99. The rest of these operations make sure that this value is associated with the appropriate coordinates.

By using a named matrix, we’re able to create a feedback loop with our animation process, which iterates once per frame.

Once we’ve got all of this, our position and texcoord matrices are packed together and added to our generated geometry matrix. From there, it is off to jit.gl.mesh @draw_mode quads to be rendered.

For more fun, try using different methods of filling the position matrix, or using video sources with an alpha channel for some blending effects.

Recipe 37: Shatter

General Principles

• Using OpenGL for Motion Graphics effects
• Particle-esque animation
• Using bline for motion curves

Commentary

Similar in structure and basic design to the TinyVideo patch, this patch uses the textured quad approach to create a nice motion graphics effect where the video image appears to break up into a bunch of little pieces.

Ingredients

• jit.expr
• jit.gl.mesh
• jit.gl.texture
• bline

Technique

This patch takes several techniques developed in previous recipes, such as the particle animation technique first introduced in Particle Rave-a-delic and the procedural generation of textured quads using jit.expr from TinyVideo. By combining these techniques with controls for velocity and an “amount” curve, we create a very different sort of effect. The displacement matrix gets multiplied by the output of bline to provide timed control of the motion.

Recipe 38: BrightLights

General Principles

• Using OpenGL for Motion Graphics effects
• Using Video Input to control OpenGL effects

Commentary

This patch uses the underlying architecture of Recipe 36, but adds in the use of a matrix input to scale the sprites, creating an effect much like a grid of lights that display the incoming video. The same luminance input that is used to scale each of the sprites can also be utilized to scale other effects such as moving each sprite around with noise. The shader included with this patch creates a feathered, circular alpha-mask for the incoming texture. You may notice that this is the first recipe to include it’s own shader!

Ingredients

• jit.expr
• jit.gl.mesh
• jit.gl.texture
• jit.gl.slab
• jit.rgb2luma
• jit.op

Technique

Here we are seeing yet another iteration of the quad-drawing expression used in previous recipes, but this time it is used for a very different effect. There are two aspects of the patch that make it work.

First, we calculate the luminance of the incoming video so that we can use that to scale our sprites. This luminance image is then downsampled because we are prioritizing the effect over video clarity, and also so that our drawing code is more efficient. This is then scaled, biased, and thresholded to give more selective control over the lights. Using a high multiplier with a higher threshold value will produce a more extreme scaling effect. This matrix is then multiplied with the output of our quad-drawing expression (jit.expr) to scale the individual sprites.

To make the light look nice and luminous, we create a big white texture that is fed through the “ab.spotmask.jxs” shader to create a circular alpha mask. This makes each sprite appear to be a bright, soft-edged light. For more of a gradual fade, the “param fade” value can be increased. Location of the spotmask can also be used to create offset effects.

Note: the included shader works just as well with video or image textures if you need to do feathered, circular masking of an image.

Recipe 39: Preview

General Principles

• Making a preview window for OpenGL scenes.
• Using shared textures
• OpenGL texture readback

Commentary

Until recently, making a preview window for OpenGL scenes was a pretty messy and difficult task, and usually involved doing all of your rendering multiple times in different contexts. Now, with texture capturing and sharing available in recent versions of Jitter, it is much easier to patch together a preview display. This recipe also demonstrates one of my favorite new techniques (and one you’re bound to see in future recipes), which is to manage rendering order using the “layer” attribute and jit.gl.sketch’s “drawobject” message.

Ingredients

• jit.gl.videoplane
• jit.gl.sketch
• jit.gl.texture
• jit.gl.slab
• jit.gl.render

Technique

The camera grabbing and image processing should be familiar from other patches. the included shader, “ab.lumagate.jxs”, is a slightly more developed version of the shader written for the “My First Shader” article.

Note that the jit.gl.videoplane objects are set to “@automatic 0″ but there is nothing banging those objects. How is this done? To see the answer, have a look inside the “render_master” subpatch. You will notice that the first jit.gl.sketch object has “@layer 1″ and “@capture sc_tex”. This means that it will be the first OpenGL object rendered, and that the output of this object will be captured directly to a texture (sc_tex) instead of being drawn to screen. The “drawobject xxx” message is used to draw our two videoplanes to the capture texture.

You might have noticed that there was a jit.gl.videoplane object in the main patch (scene_plane) that is using “@texture sc_tex”. This is used to display our captured scene directly to our OpenGL context. This is done using the second jit.gl.sketch object with “@layer 2″, which tells it to render after the first jit.gl.sketch object. This way we can be sure that there is something in our “sc_tex” texture before we try to display it.

To share the captured texture with our “preview” context, we need to set the “shared_context” attribute. From there it is as simple as setting up a named jit.pwindow and drawing a mapped videoplane into it.

Recipe 40: SceneWarp

General Principles

• Video feedback using OpenGL
• Using jit.gl.sketch to manage rendering
• OpenGL texture readback

Commentary

We’ve had several recipes already that do OpenGL feedback, so you may be wondering what prompted me to put up another one. Well, first of all, I wanted to give an example of the most efficient and reliable way to do texture readback in Jitter, and I also wanted to show you a simple warping technique using jit.gl.mesh to display the feedback texture. This recipe makes good use of the technique presented in the last recipe, where jit.gl.sketch is used to render individual objects, with the “layer” attribute defining a specific rendering order. This provides a pretty elegant and spaghetti-free way to do some more complex rendering operations.

Ingredients

• jit.gl.videoplane
• jit.gl.sketch
• jit.gl.texture
• jit.gl.slab
• jit.gl.mesh

Technique

Most of the mechanics of this patch should be familiar from Recipe 39, with the exception of the feedback stage and the use of jit.gl.mesh to distort the feedback image.

First off, you will notice that we are using two textures in the capture/feedback chain, “sc_tex” and “fb_tex”. Your first impulse might be to capture directly to one texture and then use that for feedback, but this will most likely just cause pixel trash. In order for this to work, you need to capture your scene (fb_plane,ol_plane) to a texture (sc_tex), and then map that texture to a videoplane (sc_plane). This videoplane is then captured to our feedback texture (fb_tex) using the second jit.gl.sketch and then displayed to screen using the third jit.gl.sketch.

The order that all this is happening is defined using the “layer” attribute of the corresponding jit.gl.sketch objects.

Once we have our feedback texture, it would be pretty boring just to display it untouched behind our overlay texture. To prevent boredom from dragging us all into a deep slumber, we apply our feedback texture to a slightly distorted plane (jit.gl.mesh). Over the course of several frames this subtle distortion creates a swirly and dramatic effect. Further processing can be done by adding a jit.gl.slab into the processing chain.

By itself, this recipe is pretty nice, but with a little seasoning and your own personal touches, it can be a mind-melter of psychedelic swirly visuals. Bon Apetit!

Recipe 41: Verlets

General Principles

• Generating a custom particle physics engine
• Using convolution and matrix operations to perform calculations.
• Converting procedural techniques to a Jitter patch

Commentary

Hand-rolled particle systems are a bit of a fixture in the Jitter Recipes, so when I read recently about Verlet Integration, I immediately wondered how difficult it would be to use this particle physics technique inside of Jitter. Using different constraints within the calculation loop allows you to simulate things like fabric and ragdoll physics with little effort.

Ingredients

• jit.convolve
• jit.op
• jit.matrix
• jit.expr
• jit.gl.render
• jit.gl.mesh

Technique

Before spending too much time trying to figure out this patch, it will help to familiarize yourself with the theory behind Verlet Integration. There is a pretty good tutorial here.

Since we are doing calculations on a single matrix over time, we start by setting up a feedback loop where the named matrix is at the top and bottom of the calculations. We also need to compare our current frame with the previous one to derive the velocity information. For this purpose, we use another jit.matrix with @thru 0 to store the frame. To do our basic position calculation, we use jit.expr.

Now, if we were to leave it with that, we’d have a pretty boring particle system. Where Verlet Integration really shines is when you start applying “constraints” to your system. In the patch, we have two very similar subpatches called “constraints”. These two patches compare the location of each particle to that of it’s nearest neighbors. If the particle is outside of the preferred distance, it attempts to correct the position of the chosen particle as well as its neighbor. To do these operations, we use jit.convolve to shift the matrix by one cell in either direction. Once it is shifted, we can do a 3D distance calculation to find the current distance and try to bring it closer to the ideal. All of the equations are directly taken from the article referred to above.

Once we have corrected position for the right neighbor and the below neighbor, we then take the average of those corrections and pass it to the “gravity” stage. If we wanted a more perfect distance correction, we could create another pass, but for this recipe, I decided to stick with one.

The gravity stage simply reduces the Y-value of all the cells by a specified amount each frame and then performs a folding operation to keep all the particles bouncing around in a constrained area.

Once we have done all this math, we send the matrix off to be rendered using jit.gl.mesh and send the results back to the top of the processing chain again to calculate the next frame.

Now that we have the physics engine built, we can proceed to set it in motion by repositioning different particles. Notice that all the particles start moving once you’ve repositioned one of them. This is because the “constraints” system is trying to maintain a specified distance between each particle. Try experimenting with different sorts of constraints, different calculations, or different ways to trigger movement.

Recipe 42: RenderMaster

General Principles

• Using jit.gl.sketch to manage complex rendering processes
• Capturing 3D scene to a texture
• Post-processing a 3D scene using jit.gl.slab

Commentary

Early on in the Jitter Recipes, I posted a patch called SceneProcess which took a 3D scene and processed it through jit.gl.slab and feedback. In the process of working on some recent video projects, I needed a lightweight and modular system for creating quick 3D sketches that could be combined together to create different scenes. Rather than creating a whole rendering context for each patch, I needed a master patch that did everything itself. Further, for the work I was doing, the 3D scenes would often require some post-processing to sweeten them up, like color correction and blur effects. Having this framework freed me up to make some very complex setups very quickly, and reuse parts for a variety of scenarios.

Ingredients

• jit.gl.sketch
• jit.gl.texture
• jit.gl.render
• textedit
• text

Technique

The core of how this patch functions is inside the “object_register” subpatch. The top portion of the abstraction provides an interface that converts object names typed into the textedit object on the main screen into “drawobject” messages to jit.gl.sketch. As we’ve seen in previous recipes, you can use jit.gl.sketch in this manner to draw various OpenGL objects in a controlled manner.

Another little detail in this abstraction is the messages “glalphafunc greater 0.5,glenable alpha_test.” These OpenGL messages enable what’s called alpha testing, which will check the value of the alpha channel and simply not draw the pixel if the alpha is less than 0.5. This is useful for scenes where you want to use depth-testing, but still want to have transparency with the texturing.

Inside the “post-process” subpatch you will find the texture that we’re capturing the scene to. You will notice the messages “capture_depthbits 16,capture_source color, dim 1280 720.” These messages set our texture up to enable a 16-bit depthbuffer, which allows for depth-testing in our 3D scene. If you don’t specify a “capture_depthbits” value, depth-testing won’t happen in your captured scene. From there, we pass the texture through a simple bloom filter and on to our output videoplane.

If you load the “42.RenderMaster” patch and then also load the “simple_test” patch, you will notice that the textedit in the main patch gets automatically updated with the names of the OpenGL objects in “simple_test.” This is because we’ve added in a very simple interface whereby the objects identify themselves using a loadbang and “getname” message. This is all sent along to the textedit object where it gets added to the list of rendered elements.

Using the simple framework here, multiple OpenGL modules can be built and added to a scene as needed. The post-processing chain can also be developed more to create other image effects, and get away from the sharp edges of your typical OpenGL scene.

The key behind Ralske’s work is his custom software, a series of Jitter objects called Auvi. In a generous move, he recently made Auvi available for free for non-commercial use. Ralske is also a popular Max/MSP/Jitter teacher at schools such as School of the Museum of Fine Arts in Boston and School of Visual Arts in New York City.

Die Büchse der Pandora 1929 (2009)

What were some of your first art experiences?

I have a very complicated and unusual background. I’m from New York, originally. My background is actually in music. I had a career as a professional musician, or to be accurate, a professional pop musician.

After that, I did work composing music for films, and record production. It was around that time, I became interested in electronic music, and I discovered Max in 1997. At that time, I was using Max for algorithmic composition.

A few years later, around 2000, I got interested in working with Max for visual arts. Since that time, I’ve worked with Max pretty much exclusively for visual projects.

How did you grow away from the pop music scene?

That’s a complicated question. I was always interested in a wide variety of music, and a wide variety of art. But somehow I turned from this shy teenage guy who wrote songs in his bedroom into somebody with a major record deal, who was doing tours, interviews, videos – the entire stereotypical rock star experience.

But after I completed my third album for Sony/4AD, my record label, I decided that it was just too limiting to try and work in that format. That was in 1993. I decided to just move forward, and not look back.

I am so excited and busy with the things that I’m working on now that I don’t ever think about pop music much, really.

Wow, you had a busy youth. Did you have time for college?

I went to college as a teenager, but didn’t complete my degree, at the time. I studied philosophy at Eugene Lang College in New York City. Subsequently I went back to school and completed my degree in computer science at Hunter College in New York. My grad degree is in Art Criticism from the School of Visual Arts in New York.

How did you get interested in video?

I’d always dabbled in visual arts, but in 1999 I started doing some experiments using Java to create visual images. And then right around that same time, around 2000, an extension to Max became available, called Nato, which is very difficult to explain. It was basically a very odd extension to Max that allowed you to work with video.

I was really excited about the idea of working with both image and sound simultaneously in the same program. Then around 2001 or 2, Jitter became available. I also began programming my own Max external objects for imaging, which is the Auvi software.

Tell me more about the Auvi software. So they’re objects for Jitter?

They’re objects for Jitter, written in C. Originally they were objects for running under the Nato extension to Max. But after Jitter arrived, I ported them over to Jitter. Basically, it started out as my own software that I wanted to extend the possibilities of what you could do with images in Max.

I had some very specific ideas about what I wanted, and it seemed to make sense for me to write the objects myself to get those results. Originally it started out as something for my own use. But as I got more and more into it, I realized that it might be useful to other people.

It was very educational to actually get Auvi to the quality level of commercial-grade software, so that it could be generally useful to many people. I learned quite a lot from that process. Around 2002, I released the Auvi package of objects for Nato, and then subsequently in 2003 for Jitter.

Auvi was available as a commercial product for several years, and then I withdrew it in 2008, basically because I no longer had time to update the software. This year I re-released the software as a free package.

There were really a great many people who enjoyed the software a lot, and did some interesting things with it. I decided I wanted to give something back to the Max community a little bit, so this collection of 85 Jitter objects is now freely available to anyone that wants to play with them.

Faust (Murnau, 1926) Golden Vivisection [excerpt] (2009)

So the Max community has been good to you?

The Max community is really quite generous in sharing its knowledge. And even apart from the community of users, the stuff the C74 Max programmers have done for the past 20 years is really just so wonderfully creative, and I would even say generous. Although Max is a commercial product, I feel that really there’s 20 years of love in there. [Laughs.] 20 years of really wonderful creativity.

Just speaking for myself, having used Max, MSP and Jitter for 13 years now, it’s opened up so many wonderful possibilities, in terms of making art, and subsequently in terms of my career. It’s been so interesting, and exciting, and rewarding.

Your Auvi Objects pack a lot of processing into single objects. What was your design goal for this toolkit?

I think that half-consciously, I wanted each Auvi Object to be like a guitar effect pedal. You plug it in and it instantly does something interesting. There’s an “effect” knob to control the blend of the wet and dry signals. Often there’s a “rate” knob, so the qualities of the effect can automatically vary over time—like the Auvi internal LFOs. Sometimes there’s a “threshold” knob, so the effect kicks in harder at certain levels like Auvi internal alpha control. They sound different if you crank it up and get feedback such as the Auvi internal feedback. And, it’s easy to chain lots of them together to create a big complex mess.

Is there an overriding theme/scheme behind the objects?

I wanted Auvi to be friendly to beginners, to make it easy to get exciting things to happen. You plug an object in, you instantly see something interesting—no need to initialize parameters. The objects are quickly rewarding, and provide more rewards for those who are patient enough to figure out the LFOs, internal alpha and so on.

Auvi strength is its quirky visual effects. You can create complex abstractions with little effort. VJs and other live video performers like this capability. Auvi has been used for installations, theater performances, dance performances, and apparently for live visuals for a Radiohead tour.

I feel that one of the unique strengths of Max is that you can create indeterminate systems: instead of a single piece, you get a tool that can produce many pieces. Instead of getting exactly what you want, you get a bunch of output—which, with luck, might turn out to be even better than what you originally thought you wanted.

For this reason, I put the internal LFOs into the Auvi Objects. Rather than set a parameter to a single fixed value, you set how you want that parameter to change over time. This encourages setting up systems where each parameter has its own behavior, and the sum total effect of these small independent agents can be unexpectedly interesting.

You recently changed the licensing model for the Auvi Objects to be free for non-commercial use. This will obviously increase people’s willingness to try them out. Were there other advantages to making them freely available?

It pleases me to think that the Auvi Objects are being used to help artists realize their goals. There’s been over 1,000 downloads of Auvi in the six weeks since its been re-released. So there’s an altruistic impulse, but also, I feel that if the software is being used, it justifies the two solid years of work I put into writing it. The software is some sort of a documentation of what I did with myself from 2001 to 2003.

Was Max a real challenge to learn or did you take to it more easily because you already had programming chops?

Actually, no. I did my computer science degree after I became involved with Max. One of the reasons that I actually decided to do the computer science degree was that I felt that I just wanted to go further with my work in Max, and I felt that I needed to get really solid chops in programming and understanding what was going on under the hood.

So in the beginning with Max, I was teaching myself, and I do remember some struggles in the early stages. On the flip side of that, for six years now I’ve been teaching Max to beginners, quite often art students who have no background in any sort of programming or scripting or anything. I’m always astonished how, with a good introduction and a little bit of patience, even complete beginners can do very interesting things in just a few hours of messing with Max or Jitter. With a few hours of experimentation, they will wind up in very interesting places.

How would you describe your patching style?

My patches are shamefully messy. Usually they are done to meet a deadline, and the nervous tension is visible in the way the patch is laid out. If there’s enough time, I will then select important interface items and put them into presentation view. It’s the Max equivalent to stuffing the contents of your messy apartment into a closet while your guests are ringing the front doorbell.

Do you have a favorite object?

I’m fond of button; I think it’s the most Max-like of all Max objects.

Really, and why is that?

It’s a beautifully simple and effective way of getting input to the machine, or to receive visual feedback of what the machine is doing. There’s nothing like it in other languages.

A flashing yellow button object is the heartbeat of Max.

I love your video pieces; the video is moving, but never the same, and slowly moving into each other. It’s all so intriguing. Where do you get your creative inspiration?

For the last several years, my research has been about images and motion and stasis. I think the piece that you’re referring to is a video I made in 2006, called Times Square Timeshare. For that piece, I developed this trick for inverting the appearance of motion and rest in the image.

So it’s originally just a very ordinary shot of Times Square in New York City, but in my processed image, everything that was originally in motion is standing still, and everything that was originally at rest is moving. So you see things like buildings and parked cars moving, but you see things that were in motion, like pedestrians or buses as static.

It seems that Max has opened a lot of doors for many people of all walks.

I have a lot of affection for Max, what it’s capable of, and the possibilities that it opens for the artist.

Having taught Max now for six years, mostly to beginners with fine-arts backgrounds, I’m always struck by how student’s projects turn out so completely different from each other. Max can accommodate so many different types of artistic interests, so many different ways of working, so many different mediums. From installation to performance, to still image, to sound work, network projects, software art, to combinations of all of the above.

I really don’t think that there’s any software that’s available that can accommodate such a wide range of interests.

It’s so true that it can cross so many different mediums. Doing all these interviews is just a fascinating process, hearing what everyone’s doing with it.

I’m sure.

So, you find that it’s a good educational tool as well?

I really believe it is. I think that even if people take one semester of Max and wind up not using it again, I feel they get a much deeper insight into what’s going on behind the scenes with digital media. It helps them with every sort of digital-media project they do in the future, even if it’s something as simple as understanding why Final Cut isn’t behaving the way you want it to. Students get a nice “look under the hood” from their experience with Max.

I also want to mention that I’ve done work with similar software packages, such as Processing or Open Frameworks; I do think that these software packages have certain strengths, and do seem to be very good at certain specific things. But in general, Max is so much more developed, much more intuitive, and so much more generally capable. It’s so much better for prototyping software, for accomplishing things quickly, and for working on a wide variety of projects. I still feel that Max is on top, that Max is really the superior tool.

What is the first patch that you have your beginning Max students make?

The assignment after the first class meeting is “make a patch that is complex and beautiful, but has no function.” The results are often amazing and bizarre. The point is to allow students to become comfortable with the heuristics of the Max environment. It also demystifies the apparent complexity of Max. If students can feel playful and creative with Max from the start, it reassures them that Max is indeed a good tool for artists.

How do you help students who seem overwhelmed at first?

If students are overwhelmed, it means the teacher is doing something wrong. I don’t allow my students to become overwhelmed. For the first half of a one-semester Max class, students are kept on a short leash. We keep very clear objectives; the focus is on the general principles of how Max is structured. After a certain amount of material is absorbed, the leash comes off, and students are free to run around and explore.

How do you teach students trouble-shooting skills?

From the beginning, students are constantly reminded of certain key principles, for example: “Every Max object is a separate program. It doesn’t know what is going on above or below it,” or “There are only a very small number of possible data types. Exactly which type is going down your patch cord?” or “Each object is very stupid. You need to tell it what to do!” Also, every time new material is introduced, common pratfalls are pointed out. So students develop familiarity with the errors they’re most likely to encounter.

What would make it easier to teach Max?

Some beginning students are intimidated by the help files, they seem to contain too much information—however they’re fine for more experienced users. Students seem to have difficulty finding what they need in the documentation. It’s not easy to search on how to accomplish a specific task. So, a directory of solutions for commonly needed tasks would be a great addition to the documentation.

What are some of the surprising projects that your students have come up with?

My students constantly surprise me. Rebecca Adorno at SVA used Max and
Arduino for a beautiful interactive installation called Instrument for Unsent Letters that uses an old-fashioned manual typewriter to control robotic string instruments and audio playback. Amanda Cassingham at SMFA made an MSP patch to translate room ambience and environmental sound into spontaneously generated texts. Zeljka Blak extended our first assignment—the non-functional patch—into her final project, and made a crazy parody of the conventions of software interface design. And Matthew Gaertner at SMFA spent an entire semester single-mindedly focused on the ritualistic abuse of a single Max object—”Button”! [Laughs.]

Kurt’s Website

Auvi software

Text interview by Marsha Vdovin and Ron MacLeod for Cycling ‘74. Video provided by Kurt Ralske.

In it, a young princess, whose kingdom’s riches are dependent on a gold excreting donkey, orders the impossible from her doting stepfather to thwart marrying him: three dresses made of immaterial materials. The first is to be made of the “sky” and should be as light and airy as the clouds. The second is to be made of “moonbeams” and should reflect the same lyrical intensity as the moon at night. The third, and last, is to be made of “sunlight” and should be as blinding and warm as the sun above.

Can you tell me a little about your background?

My background is in visual arts. I studied art history and fine arts. I did an MFA, a Master of Fine Arts, in painting.

Where was that?

That was at Concordia University in Montréal, both at the undergraduate and the graduate level. I’m presently enrolled in a Ph.D., also at Concordia, researching “Performativity, Materiality and Laboratory Practices in Artistic Wearables.” So I’ve been there for a while.

Are you from Montréal?

I’m French Canadian, so I was born in Montréal. However, my parents were hippies, and worked in theater, and then in film. They both did design and technical direction. This made for a lot of moving. I lived back and forth between English and French Canada, and the U.S. and Canada. In the U.S., we lived in Minneapolis, because the Guthrie Theater. We also lived in North Carolina for a while, while mother did an MFA at the North Carolina School of the Arts and where I later enrolled and studied acting for one year — I was a terrible actress.

So you were brought up in a really artistic household?

Yes, it was exceptionally artsy. In my early twenties I was rather critical of the theatre and thought: “This is not real art, because you’re working for a company, and you don’t have the autonomy of creative genius.” But now that I work in new media, and it’s all about teams, of course I don’t think that way any more about creative and collaborative endeavors.

The theater is a great context to learn about building stuff and presenting technology with people in a performative context. What I’m doing now, in terms of wearable art, involving the body, goes back to that. I’m looking at performance, performativity, and how the presentation context can add to the live-ness of interactive artworks. Also, for me, technology is performative.

But you started your MFA as a painter?

For the MFA, I enrolled in painting, but I ended up doing performance. I did relational performance, which had an important component on the Internet as confessionals or portals for exchanges. This was in 1999/2000, so people were just beginning to do really creative interventions on the Internet — in fact the Internet was a very performative medium at that time, like e-toys or Mouchette. People were ‘posing’ as all kinds of things, because the web can mask identity, so identity is always constructed.

In fact, it was through these on and offline performances that I ended up making the Peau d’Ane project. I was doing a lot of performances that involved the costume as the key element to the performance. The performance that I did for my MFA thesis show was called The Advice Bunny. I dressed up as a bunny, and I gave advice, sort of like Lucy in Peanuts. [Laughs] There was an online forum and web site where people could ask for advice as well as a ‘psychoanalytical’ consultation office.

My performances of that era were focused on framing interaction with individuals, either on line or in real life contexts, where I would set up offices, and booths, and people could come and meet with me. For example, I did another performance about a nurse unlocking the public’s sensory perception through a series of props that were used on the public — scented oils, picture books, sandpaper etc. So again, sort of an incarnation, a sort of persona. I also did a performance based on Hans Christian Andersen’s Snow Queen, which involved making snowflakes in a very large installation with about 2,000 hand cut snowflakes decorating the space as a context for making snowflakes for the public as a performance.

Working with relational performances which focused on exchanges led me to wanting to make a costume, which would have its own interactivity. I am interested in the agency of objects, and their ability to perform — not just us — and I wanted to explore a format which would bring the technology and the body together in a performance context. Wearables, because they are garments, have that potential to phenomenologically transform us — through technology. This is and remains very interesting to me. I remembered a fairy tale called Peau d’Ane [Donkey Skin], which had three fantastic dresses — one could even call them impossible dresses — made of the moon, sun, and sky. In the fairy tale the princess requests them as a test in order to avoid marrying her own father. Clearly she believes that they cannot be made, though they are made! I thought: Wouldn’t it be great to make them? To make them really interact with these components? So, I made a Moon, Sun, and Sky dress.

I began doing research in wearable, smart textiles technologies and materials, and looking into ways of creating an interaction between the garment and the environment. It was the meeting of this fairy tale, and relational performances involving costumes, which led to Peau d’Ane.

How were you introduced to Max/MSP?

I took a class at a women’s media centre in Montreal called Studio XX and I ended up enlisting my teacher, Patrice Coulombe, to help me. It was an interesting exchange because he was interested in learning more about physical computing, and I was just beginning doing research in that area. Tom Igoe and Dan O’Sullivan’s book Physical Computing: Sensing and Controlling the Physical World with Computers had just come out, so this was a new area of exploration that was becoming more accessible for artists. Patrice really collaborated quite significantly for the Max/MSP components of the project. There are layers of complexity that I couldn’t really deal with, and that even Patrice didn’t know a whole lot about at the start of the project. We explored the project together over almost 3 years. Also an engineer / artist, David Beaulieu worked on the electronics in later stages of the project to create customized circuits.

For the wearables, I am now working mostly with Arduino, and more specifically the LilyPad Arduino. At the time of the Peau d’Ane project we were using a charlieplexing chip which had not been integrated into the Arduino toolbox, so we had to design our own circuits. In fact, Arduino didn’t even exist when we started the project.

What is Arduino?

Arduino is an open-source electronics prototyping platform. A company called Arduino in Italy makes them and they have really democratized the field of electronics for artists by making circuits which are easily programmable and designed for artist / interaction designer’s use. For people who are interested in physical computing, they’ve packaged a series of components, and circuit boards to build your own micro-controllers. They could be used for stand-alone work or they can communicate with software, like Max/MSP.

Specifically Leah Buechley, now at the High-Low Tech Group at MIT, designed a circuit and a series of sensors / LEDs etc, which are made for wearables. The design of the circuits are adaptable to the use of other wearables materials such as conductive threads and materials. The Arduino programming language (called Wiring is based on Processing) is very simple and very well documented — kind of like Max/MSP! That being said, it’s always possible to design your own circuits. I am not necessarily pro-Arduino — I always encourage my students to start by making their own circuits, it’s much cheaper and you learn a lot more — Arduino just makes it quick and accessible and is very stable.

However, in the case of Peau d’Ane, because we were interpreting specific environmental data, we needed a solution for i/o. There’s a small weather station, made by a company called Davis, which is for weather enthusiasts. The great thing about it is that it functions wirelessly. So we are able to have a console that could be plugged into a main computer, and then the Max/MSP patch took the incoming data from this particular console.

In the case of the Sun dress, you have input from the UV index, solar radiation, and temperature. The Sky patch interprets data from wind velocity, and wind direction. For the Moon, we programmed it to represent the 28-day cycle, without the need for the Davis console, of the moon by activating a series of 14 flowers which increased in activity for 14 days and then decrease for the next 14 days — following the waning and growing moon.

What’s interesting about working with the weather is that is very site and time specific. I live in Montréal, so there’s a radical difference between the kinds of readings you’re going to get in the winter versus summer. I’ve also traveled with this project to Peru and to Europe, so depending where you are at different times of the year, you’re going to get really fluctuating readings. So the question came up: “how do you build something which can accommodate all these differences?”

For example, in Peru, it was sunny all the time. If you have your parameters set for a certain UV index; it may reach a certain level and then stops transforming itself because it hasn’t been programmed to be sensitive to small changes with a high UV/temperature range. So it might always be within a certain range, and not as active, or responsive as it might be in a different environment. We learned that parameters had to be adjusted accordingly for every climate.

So can you reprogram it on-site?

Yes. The patch is made in such a way that the outputs can be reconfigured at all times, so I can readjust them on the fly. Let’s say I presented the Sun dress, in Ghent [Belgium] at one point, and it was really only sunny for one morning. I clearly would have to rethink what the parameters of the reading of the dress would be. We encountered that scenario the first time I presented the project at the Vooruit.

What we did was adjust the parameters so very small fluctuations in temperature would trigger the dress to react. The Sun dress has 128 LEDs, so what it does, in essence, is that the moment that there’s a change in the Davis device readings, based on these three different parameters — the UV index, solar radiation, or temperature — it will begin to ‘play’ a different sequence of LEDs, and it will continue to play that sequence in a loop until there is a change in one of the three inputs. So that’s why one has to research what the weather is like in that particular location if you want the dress to do something interesting. Otherwise it could just stay stuck in one parameter, and not really do anything more.

And the same goes for the Wind. Some cities are windier, or some times of the year are more dynamic. You want to program it to have the parameters be within the range of what the weather is in that particular area, otherwise, it’s just not that exciting — not that the weather is particularly exciting — but the goal is to also create an artistic experience, so we have to ‘tweak reality’ at some levels.

In terms of technology inside of it, the Sky dress has small ventilators, and electronic components blowing into the dress, so that’s how it inflates. One of the things that I wanted to do with it was to also have it aspirate, so that it could deflate. But unfortunately, the hardware that I used wasn’t able to accommodate for that.

The Moon dress uses thermochromic inks, with resistive heating, so when you run the electricity through the threads, it heats up the paint, and that makes it change color. For all three dresses, the interior and exterior, all of the circuitry is made with conductive threads. The wireless communication is an ICSB, so that’s how it’s communicating the data with the computer.

What Max/MSP does is that it permits us to play with the programming, to observe the data coming from the weather console and create events, which we feel are interesting and dynamic enough to represent the weather fluctuations in that particular location.

How about the dresses themselves, did you design and sew them?

I worked with a fashion designer, Lynn van Gastel, to build the dresses. I had design ideas, but she had more technical experience in terms of building garments. We were looking at dresses and designs from the Twenties, so early Coco Chanel, or Madeleine Vionnet, designers who were really avant-garde for their era — such as Sonia Delaunay — were quite influential.

The Twenties were an exciting period — it was the beginning of industrialization and technological advancements in textiles. They used a lot of graphic modern elements, so that’s why, for example, the Sun dress has these chunky components to it, different chunks of colors. The Sky dress is a little bit more princess-y, because it blows up, but it seemed to make sense that if you’re going to use the wind, you had to make something that was going to get really big. The Sky dress was in fact inspired by the late Alexander McQueen.

So it was a combination of the aesthetics that I was interested in, and the technical parameters. What is possible to make these dresses be both technically and aesthetically compelling?

Do you think you will continue using Max/MSP on future projects?

Yes, I would like to. In the department that I teach in, Design & Computation Arts at Concordia University, I always direct my students Max/MSP as a really exciting platform to do things, and not just for audio.

The limitation that I have with the wearables work that I am doing now, though, is that I’m trying to integrate all of the computation, and all of the circuits, into the garment. But Max/MSP, of course, is all in the computer, so that forces you to always deal with wireless communication. To be honest, in terms of the Peau d’Ane project, the wireless communication is the weakest link, because it’s the one part that can really mess up. If the communication isn’t working, then the garment can’t work.

So that’s why I’ve ended up using the LilyPad Arduinos. Of course Max/MSP is so much more sophisticated, and so much more versatile, in terms of producing things that can be transformed or adjusted in real time. I’ve done real time performance things with the dresses, since I have this interest in performance. I’ve played with the Max/MSP patch, transforming them in real time while someone wears them. And you can’t do that if you’ve just programmed a chip to only do only one thing.

I think Max/MSP has the most flexibility, in terms of doing things creatively. But as I said, the worrisome thing is always the wireless communication. I’m looking into mobile phone communication for upcoming projects and hope to be able to keep using Max/MSP. As I said - I think it’s brilliant software!

What will you be working on next?

I’ve started a company called 3lectromode. With 3lectromode I’m innovating in the field of wearables by combining technology with customizable prêt-â-porter [off the rack, ready to wear] fashion. We are a small group of researchers: Magalie Coulombe-Noël, one of my former students at Concordia has a background in fashion design so we have been collaborating on some projects. We are developing accessible wearables that combine D-I-Y technology with current fashion research. We’ve created kits — a series of dresses at this time — which can be bought either as a D-I-Y kit with all the components and a dress which is printed on a custom fabric printer integrating the pattern and the graphics onto one piece of textile — you just cut the dress out and assemble following the directions. Or it can also be bought pre-assembled. We want wearables to step out of their geeky niche and really be a part of fashion. For example, recently some of the couture houses — Chanel, for example — have integrated technological components in their designs such as a light-bulb enhanced heel on a shoe.

I’m also fascinated with the potential for technology to create new modalities of interaction between the body and its environment, so we are interested in the performative potential of technology. The work I’ll be making with 3lectromode will be focused on how wearables can be ‘performed’ and how the experience of wearing wearables changes our every day relationship with the clothes we wear and the environments we engage in. The Futurists were very interested in this, so, I am once again going back to the early 20th century for inspiration. Also with 3lectromode we’re aiming to develop a library of open sourced tools — ways of rapid prototyping patterns and designs as well as circuits adaptable to wearables — which can be used easily by anyone to create their own fashionable wearables.

The motto for 3lectromode is: “Creating a future where wearables are democratized, aestheticized, and performative.”

Valérie’s Website

Interview by Marsha Vdovin and Ron MacLeod for Cycling ‘74.