Darwin Grosse

It all started one day during a conversation with a friend. We were talking about something, and I realized I had the perfect photo to enhance the discussion. I also realized that it was in My Great Big Archive, and that I would never be able to find it.

This was pretty depressing, but it also got me thinking: I have a huge (16 TB) backup disk that contains almost all of my life since about 2005. How many photos were on that drive? And would I ever see any of those images again?

I decided to change things: I may not be able to categorize/tag/sort all of the photos that were collected over the years, but I certainly could make sure that I had the chance to see them! I decided to make a Max-based photo viewer that would be robust enough to traverse any hard drive – including my 16 TB monster.

In order to pull it off, I needed some industrial-strength help. So I turned to the Node for Max objects. I remembered that there was an example in the Extras patch that offered file system access; I figured that would be the right place to plumb for the tools to get the job done.

Working one's way through a file system is a classic example of recursive programming: you have a function that gets a directory listing, and if any of the items are subdirectories, you call that same function with the subdirectory. It’s an elegant way to walk through a file system, but in practice it can also be tricky.

In trying to traverse a large file system, I started with the Node for Max Extras “fs” example as the starting point.

My first modification was to find images and return their file paths whenever they were found. This example asynchronously does file system recursion, and it pointed out a problem with asynchronous behavior: it created enormous number of simultaneous folder requests, then started generating an equally enormous number of Max messages with found images. Immediately Max got overwhelmed, with messages getting ignored, and eventually crashing Node. 

I knew that the Node fs module had synchronous versions of all the calls, and that would provide a single thread of execution – so that I would only have to manage a one file discovery at a time. So I changed the fs calls to synchronous versions (for example, using readdirSync() instead of readdir), hoping that this would provide for better processing. It kind of worked, but the synchronous functions are quite ‘greedy’, and really kill the system while they are running. 

I found that Max – and the computer itself – got very unresponsive when using the synchronous functions, and so I had to abandon that approach, as well

The third attempt used something in between pure asynchronous and pure synchronous code: JavaScript’s async functions and the await keyword functionality. You can find out more about this on Mozilla:

https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Asynchronous/Async_await 

Using this system, you can create asynchronous functions, but pause the program’s execution until they return from processing. 

// findFiles: kick off a volume traversal
async function findFiles(vol) {
	var v = vol;
	if (isMac) v = '/Volumes/' + v; // Mac formatting

	await maxAPI.outlet("info", "volume " + v);
	await findRecursiveHelper(v);
};

.
.
.

await findFiles(vol);

This is the best of both worlds, because I can control the order of execution while I’m still allowing for asynchronous processing – which keeps everything responsive. I now had a Node for Max script that could run through an entire hard drive without crashing or choking Max.

But just spewing out image file names wasn’t going to be sufficient – I would also have to be able to wait while my Max patch did something with them. This is a little tricky in a Node for Max script, because I don’t want to make assumptions about how long it will take for Max to process the file information. So I created a waitForBang() function that would do what it says: pause the script execution until it received a bang message.

This function does two things: it returns a JavaScript promise that will need to be resolved, and it stores a function for resolving the promise in the variable named promResponder. To pause the script execution, just call the waitForBang() function via await and the script will patiently wait.

Now, when a bang message is received, if promResponder is non-null, it will resolve the open promise and allow execution to proceed. 

// handlers: set up the message handlers (from Max)
const handlers = {
.
.
.
	bang: function () {
		if (promResponder) {
			(promResponder)();
		};
	}
};

Again, all of this is provided by that await functionality.

With so much of the heavy lifting being done by the Node for Max script, the Max patch itself is relatively simple. It includes all of the tooling required for N4M processing (the node.script and node.debug objects, as well as messages to start and stop the script), the patching required to take the file path information produced by the node.script object, and display it in a jit.pwindow. I also send the path of the image to a message box so that I can see that information when a particularly interesting photo appears. (Note: Make sure to change the file path in the 'run' messagebox to point to the location you would like to begin your search!)

What is interesting is the way that we send the bang message back to the script to continue processing after an image is found: The right outlet of the jit.matrix object is normally used to dump information about the enclosed data, but it also outputs a message whenever an importmovie request is processed. By producing a bang whenever this message is received, we know that the image has been processed. However, if we would immediately send the bang, it would proceed without waiting – and we would not get much of a chance to see it.

So we delay the bang a little - 500 ms by default, but you can change it to change the length of time that the image is displayed. We then send the bang message to the script, and processing will proceed.

The question remains: did it help me find the image I’d recalled? Not really – there were simply too many photos to review individually. But once this program started running, I got a chance to see photos I thought I’d never see again, and even some that I didn’t even remember taking. I also got to see a lot of silly photos that were stuck in NPM packages, website archives and other obscure corners of my hard drive. The patch ran for days, and every time I poked my head in the room to check its progress, I would get mesmerized by the stream of images I would have never otherwise encountered.

Of course, the idea of traversing through massive data stores opens up other interesting ideas. What if you searched for all of the movie files on your system, and displayed them end-to-end? Or found all the random audio files scattered on your hard drive and had a ‘auto-DJ’ create an abstract mix? The ideas are endless – so have a blast!

image3.jpg

One day during a conversation with a friend, I realized I had the perfect photo to enhance the discussion. I also realized that it was in My Great Big Archive (16 TB) backup disk that contains almost all of my life since about 2005. How many photos were on that drive? Would I ever see any of those images again? I decided to make a Max-based photo viewer that would be robust enough to traverse my monster drive.

file-system-traversal-for-fun

File System Traversal - For Fun!

To wrap things up, I want to make a connection to the real world - to hardware. In previous iterations of this series, we created a complicated pattr-based preset system, then coupled it with an equally complex routing system. When using the system, I seldom found this useful - rather, what I really wanted was hands-off preset selection, and simple volume control from a foot pedal. So we again diverge from earlier versions and create a simple - but effective - MIDI pedal connection. 

There are a few different guitar-oriented MIDI rigs out there, and some have been around for a long time. However, a relatively new (but still affordable) option has arrived: the IK Multimedia iRig Stomp I/O. This shortboard-styled system combines a guitar-oriented audio interface with a set of pushbuttons and a foot-potentiometer, which is exactly the kind of system that can activate our guitar rig.

With a little investigation, we find out that there are several ways of using this as a stock MIDI pedal interface. We are going to choose the easiest one - the default mode, which causes the buttons to transmit MIDI Program Change messages, and the pedal providing a straight MIDI CC. Since this is the device's default mode, we don't have to do much other than connect it right up to the computer with a USB cable, connect our guitar and an amp (or headphones) and dig in!

There isn't anything too special about the MIDI produced by the iRig Stomp I/O, other than the fact that no notes are generated; rather, everything is Program Changes or Continuous Controllers. But we do have to select the device as our MIDI input - and parse out the MIDI stream for useful information. 

To get this functionality, we are going to steal directly from one of the help files: specifically, the midiin help file. This gem provides us with the information necessary to select from the available MIDI input devices (of which the iRig is most interesting). Pairing that with a midiparse object allows us to get the Program Change and Continuous Controller messages.

To make things easy for ourselves, we'll route the Program Change messages to a send named pgm, and MIDI CC #11 messages (what the foot pedal produces) to a send named pedal.

What should we do with the data? Well, the Program Change messages are pretty easy: we'll just route them directly to the Preset Selector for direct snapshot selection.

For the CC we need be a little thoughtful - and our Overdrive/Gain system is a good place to route this data. By altering the volume before it gets to the delay systems, we'll be able to create interesting swells that get carried forward by the delay (and looper). It's a simple effect that is incredibly musical.

And with that, we hit the end of this series. The final result, with all effects, preset/snapshot management and MIDI interface, end up being a tight little system with a lot of flexibility.

How is this different/preferable to something like IK Multimedia's iRig software, or Guitar Rig, or any of the other virtual guitar rigs out there? It's because you have the ability to extend and improve this setup in ways that only you can imagine. Think about adding VST's, Max for Live devices, or Gen processors to expand your effects system - it's truly an endless playground.

Thanks for following along, and if you have any questions - just drop a comment. Happy patching!

Learn More: See all the articles in this series 

MIDI_pedal.png

Here we are at the close of our series on creating a guitar processor in MSP. To wrap things up, I want to make a connection to the real world - to hardware. In previous iterations of this series, we created a complicated pattr-based preset system, then coupled it with an equally complex routing system. When using the system, I found that what I really wanted was hands-off preset selection, and simple volume control from a foot pedal. So we’re ending this series by adding a simple - but effective - MIDI pedal connection. 

max-8-guitar-processor-part-6

Max 8 Guitar Processor, Part 6

Gregory Taylor

Welcome to the next part of my MC journey. As I said when I started this trip, it was personal. While I love opening other people’s patches and twiddling the knobs and adjusting the sliders and enjoying the results, I’m usually in search of some sort of inspiration that I can yank sideways into the place where I work.

For this "step along the way" in the MC journey I thought I'd show you another real-world bit of MC patching that takes a number of past projects/tutorials I've created and combines them with what I've learned during this series to make something that I (at least) find interesting and useful.

As I said earlier on, I'm generally not someone who's necessarily moved by MC's ability to control very large numbers of things (although David Zicarelli and Tom Hall's appearance at the Ableton Loop event really impressed me and probably got me intrigued in the first place — you really ought to download the patches and watch the video of the presentation!). But there are places where I've listened to something I've made and thought that perhaps the MC functions would let me explore them on a "slightly larger scale."

One tutorial I've recently written for the Cycling '74 website that comes directly out of my own practice and interest set was borne of my interest in exploring the 4MS Spherical Wavetable Navigator and wondering how I might use gen~ to create something interesting. The resulting tutorial — Winter's Day gen~: The Wavetank — led to the creation of a patch that let me load an 3d grid of waveforms that would be traversed to create an output that morphed interestingly.

It was lovely, but I found myself thinking about what MC might do for me there. How about an MC version of that patch whose pitches and X, Y, and Z traversal values could be independently controlled?

I've also been really interested of late in chaotic attractor equations what I could use in places where a simple LFO wouldn't get me the kind of slowly changing outputs that seemed more to me like "intentionality." I found myself wondering what use I might make of patches like this. Since chaotic attractor patches are heavily dependent on the initialization values (and not all possible values are created equal when it comes to chaotic behavior), any MC versions would start from precisely the same place — I'd need to think about spreading out the results in time or modifying them in some other way.

The value of my careful and pretty personal perusal of MC features (see the previous installments in this series) also gave me a pretty clear idea of how I might approach this. This tutorial is a walkthrough of using MC to realize those ideas.

The morphing wavetank I created in the Winter's Day gen~ tutorial is an idea that’s stuck with me since first I started twiddling dials on the 4MS Spherical Wavetable Modulator Eurorack oscillator and wondering whether I could use gen~ to do something similar.

If you’re interested in the gen~ patching that underlies how it’s done, I’d recommend you take a look back at the original tutorial. Simply put, I created a patch that let me take an audio file composed of a specific number of single-sample waveforms and create a cube (3x3x3 or 4x4x4) I could traverse in 3D using three parameter values to represent a height, width, and depth location within the cube. The resulting outputs was an interpolated result derived from the 27 or 64 waveforms. By modulating the X, Y, and Z parameters, I could produce an interesting morphed output — particularly when driving those parameter values using a set of LFOs.

On reflection, the MC toolkit suggested some really interesting possibilities:

I could use MC to create multiples instances of the morphtank patcher tuned to different frequencies — chords, harmonic multiples, etc.

I could also create some patching that would change the X, Y, and Z inputs for the morphtank patcher at different rates, from different offsets, and so on. That might be cool even if all the morphtanks were running at the same base frequency!

I could use MC tools to spatialize/control those multiple outputs.

In short, it was a perfect candidate for my next MC project.

Creating the MC patch was simple: just add an mc.gen~ @gen morphtank @chans 16 object to my MSP patch. Presto — 16 morphtanks ready to go!

There were a couple of things that I wanted to keep for all 16 instances — the control of the audio files used for the wavetank and its parameters. But when it came to setting the base frequency for each of the 16 morphtank patches, my MC investigations gave me two attractive options:

I could use a harmonic (or subhamonic) 1 <frequency> message connected to an mc.sig~ @chans 16 object to set my instances to frequencies based on the harmonic overtone series.

I could also use the spread messages in combination with an mc.sig~ @chans 16 object to distribute the base frequencies of each instance across a linear frequency range I could specify.

Based on my MC journey, I opted for the second approach, since I realized that the spreadinclusive message that I'd investigated in Part 1 of this series combined with an interesting frequency range could produce some interesting and dense “chords.”

Dealing with the outputs was just as easy, but I need to talk a little about using my chaotic attractor patch first. I’ll come back to that in just a bit.

In my initial explorations of the morphing wavetank, I'd either manually adjusted the three sliders that set the "position" in the cube I wanted to interpolate waveform output from, or I connected up some LFOs with their outputs set to a 0.0 - 4.0 range to animate things automatically.

But the more I listened to the LFO results, the more I thought about what I might use for a little more complex X, Y, and Z parameter input. It might have been the result of my using a single LFO with rate~-driven outputs that modulated the three parameters in cyclic fashion that started me thinking in this direction, or the more simple observation that I don't play faders "like they're LFOs" when I perform.

In any case, that insight got me thinking about using Chaotic equations as modulation sources; they generally appeal to me because there is a kind of trajectory to their outputs that is neither "random" (which I certainly am not) nor periodic in the way that an LFO is.

And as I said, the attractors have been an interest of mine for a long time. The very first Gen patch-a-day feature we did back in 2012 included an example I figured would be perfect for use — a trio of patches that implemented a Navier-Stokes equation in three different gen~ formats (a gen~ operator version, a gen~ expr operator version, and a codeboxed version). You'll find it on day 14 of the Gen patch-a-day series.

It's an old patch, and the intervening time has led me to reconsider how I'd implement it:

Instead of using a train~ object's output to drive the attractor, I've opted instead for a version of the patch that's "always on." With each tick of gen~'s single sample clock, the attractor calculated the next iteration of itself, and then multiplies the result by a very small value that provides the "rate" at which the attractor runs. That small value is then added to the previous one and stored in a history object. The result is a smooth output at a widely variable range. Turning the attractor "off" is a simple matter of setting the dt (change in time) parameter to a value of 0. And the attractor can be restarted at any point by sending the gen~ object the message restart, which resets all the history objects to their initial state.

The other change in my gen~ patcher has to do with improvement to the idea of establishing the limits of the attractor's outputs. You'll notice there's a second gen~ patcher added at the bottom there.

In the past, I’d simply coded up the attractor, turned it on and let it run for a few days, and used whatever the relative maximum and minimum limits I had when I stopped the patch from running (we called it “empirical observation”).

However, when I made the switch to the "add a settable increment’s worth of calculation to the previous value" instead of a train-based approach, it occurred to me that I might see slightly different results at different speeds. Since chaotic attractors not only exhibit “sensitive dependence on initial condition” (i.e. you may get very different results depending on the original settings for the initial parameters), it’s also the case that since chaotic equations iterate based on previous values, a single result that varies considerably from the previous one.

This simple change in my gen~ patcher has introduced me to an interesting problem I’m still thinking about: What’s the best way to establish and work with maximum and minimum values when you don’t know what their range is likely to be? Working with chaotic equations generally threw this into sharp relief for me since the behavior of an attractor calculation — in some cases — seemed to produce different results for maxima and minima depending on the dt for the calculation. If I changed the dt value, I might suddenly find that the relative maxima and minimum values changed. I thought that finding a way to smooth that change over time might be the best solution.

Then I remembered George Lewis talking about just this particular kind of problem with respect to his Voyager program during an interview I did with him earlier this year: He was talking about using “leaky integrators” to manage slow changes in values like this.

Simply put, a leaky integrator is easy to make: Instead of using min and max operators to set and store the relative minimum values forever, you store the next maximum or minimum value when you find it. 

But you also add some patching that slowly lowers the minimum or maximum values over time.  subtracting very small amounts from the minimum value, as well. This slowly changes the amount of the current maximum or minimum by subtraction that’s stored for the next calculation — it “leaks.” Whenever a new high or low value comes along, it sets the maximum or minimum to that new value and it starts leaking again.

I wasn’t sure that I’d have this particular problem at different dt rates, but I thought it’d be best t be cautious, so I mocked up this version for my patch:

Why didn’t I go with that initial min/max > history solution for my leaky integrator? In fact, there’s a very subtle problem with it that didn’t occur to me until my friend Graham Wakefield pointed it out to me; while this solution might work in a situation where the relative maximum and minimum values I’m tracking fall on either size of zero, I’d encounter difficulties in a situation where the relative maximum and minimum both fell above or below zero — the system tends toward zero. The more useful and general case is to create a patch where the leaky integrator’s maximum slowly approaches the minimum in the absence of new maximum values, and vice versa. This makes the patcher more generally useful.

Here’s a version that does just that — the limits now converge on each other by a settable amount (controlled using the param operator and dividing by the current sample rate to get a very small number) to control the rate of “leakage.”

Armed with this new Navier-Stokes gen~  patch, I was ready to start modulating the X, Y, and Z plane traversals for my MC Wavetank.

When it came to setting the rates for the 16 instances, I once again availed myself of the spread messages to set a range for the rate of the attractors' operations.

The nice thing about my Navier-Stokes attractor gen~ patch is that it gives me 5 different outlets. I only need three for modulating the Wavetank’s 3d controls, so I started thinking about what else I might do with two more parameters to play with for my 16-channel Wavetank. It wasn’t too hard, really — I thought I’d use one of the leftover attractor outputs to set the output amplitude for each Wavetank channel, and the other one to pan the result across the stereo field.

All of those operations would require scaling the output range of the Navier-Stokes attractor patch’s output: the first three parameters needed to scale the audio range outputs to the 0.0 – 4.0 value I needed for the Wavetank 3D controls, and parameters four and five both needed to be scaled from bipolar to unipolar ranges. Five well-placed mc.scale~ objects took care of that problem with little muss or fuss. After scaling, the Wavetank inputs went straight into the MC version of the gen~ morphtank patch. Similarly, the amplitude was handled by an mc.*~ object.

Amazingly, I was very nearly done! All I needed was to set the panning for the 16 individual outputs. Having made my way through the MC panning resources available to me in Part 2 of this series, I knew just how the mc.mixdown~ operator handled panning. I went with mc.mixdown~ 2 pancontrolmode 0 object, which spread the panning out across the stereo field by assigning 0.0 - 1.0 values for left-to-right panning. The fifth parameter outputs from the Navier-Stokes patch (scaled for the 0.0 – 1.0 range) set the panning for each of the 16 Wavetank outputs with a single patchcord connection:

My MC patch was ready for prime time. I turned it on, and... Wow. <Insert some serious tweak time here>

Before I go, I wanted to mention one more little personal tweak that produced some interesting results. As you might imagine, each of the chaotic attractor mc.gen~ patches outputs exactly the same values at the same rates (even though each instance runs at a different rate, the 5 outputs are all clocked the same). I started thinking that a further way to introduce some variety would be to consider "rotating" the X, Y, and Z outputs being sent to the MC version of my morphtank. Since each of the 16 instances would be clocked differently, rotating the X, Y, and Z inputs would mean that each one of them would update at different rates.

So I started researching how I might consider implementing a rotation for those outputs. As I always do, I check the in-app Max help first. There was some discussion about using an mc.matrix~ object, but that looked pretty daunting (and I'm not ashamed to say it). What I did find in the "Search the Forum" results was that Timo Hoogland had produced a suite of MC utilities (available at no cost, although he would appreciate you filling the tip jar, I'm sure) that include an abstraction that does just that. You might want to try it (I obviously can't give you a copy of someone else's work, but here's how I added it the main patch):

image2.png

For this edition of the MC journey, I’m going to combine some longstanding interests of mine (using materials from earlier tutorials) together with the MC tricks I’ve acquired during my journey to create a rich, undulating bed of morphing MC drone. 

an-mc-journey-part-4

An MC Journey, Part 4

One of the features of gen~ that has interested Max users from the beginning is the ability to create patches that process audio input on a per-sample basis (as opposed to MSP, which bases its processing model on groups of samples, called the signal vector size). Single-sample processing in gen~ means that the signal vector size no longer set the shortest allowable delay time in samples to the current signal vector size, which lets users experiment with things like pitched/ringing delays. You can find a tutorial exploring these features here. 

Another area in which gen~ users have ventured involves using gen~ to explore and implement various varieties of audio filters. While there are a lot of examples of audio filters that are specified using mathematical formulas...

...audio filters are also often depicted using block diagrams rather than mathematical equations. You can use those block diagrams in your gen~-patching practice to create those filters using standard gen~ operators, even if you're just getting started in your Gen journey. In this brief tutorial, I’m going to

Show you a couple of simple examples of filters implemented in gen~, and show you a neat trick that’s helped me make sense of using block diagrams to create gen~ patches, and work through a couple of simple examples.

Give you a little advice about what to watch out for as you explore this area further (to avoid some of the problems that bedeviled me along the way, to be honest).

A First Trip Around the Block (Exercising Your Biquad Muscles)

Let’s start with an example of a digital filter that every MSP user knows and loves: the biquad (short for biquadratic) filter. People love this general-purpose digital filter because you can set it up for practically any configuration by doing nothing more than adjusting the parameters (or coefficients) for the filter. 

In the MSP world, the biquad~ object is an implementation of this incredibly versatile filter, and Max/MSP helpfully includes a couple of external objects that provide a graphic interface that outputs filter coefficients to the biquad~ object (the filtergraph~ object), as well as a non- graphic object for outputting those coefficient values (the filtercoeff~ object).

In fact, it may be the very first glimpse you've ever had of a filter block diagram! In fact, if you take a look at the coefficients tab of the biquad~ object’s help file, you'll find a block diagram of a biquad filter,.

Spoiler: This block diagram has an error in it. We'll talk about that in a minute.

Here’s a standard block diagram of one version of a biquad filter from the Wikipedia article on biquadratic filters:

I'm showing you both block diagrams to make a point: It's often the case that the same block diagram is depicted in slightly different ways, so it's helpful to see if you can find more than one example of any filter (or physical model or waveguide) block diagram you want to use to start from.

You can think of this block diagram as a map of the flow of data, and — as with any map — you always need to start by getting the lay of the land. In terms of the overall input and output, the flow of data is left (starting at x[n]) to right (ending with y[n]), with arrows generally demonstrating the order in which calculations are done. Several graphic items show up and are repeated several times

• Three big circles with a cross in them

• Smaller hollow triangles that are labeled

Decoding them will help us to see what’s going on – because each of those symbols will be replaced by a gen~ operator (or operators, sometimes) when we create the filter patch. Let’s look at each one:

The Z boxes are a convention used to represent single sample values. If Z is the current sample, then Z^(-1) is the previous sample. 

Some filter block diagrams use variants of this to indicate “N samples ago”  by Z^(-N), where N is the number of samples’ worth of delay, or — in slightly more rare occasions — Z^(-M) to indicate a moving sample value rather than a fixed number of samples. In gen~, we can represent “the previous sample” (Z^(-1)) using a history operator.

You’ll notice several circles with a cross in them. It's not a cross at all — it’s actually a gigantic plus sign rather than a graphic of some sort. The arrows helpfully indicate what things are being added together and where the result of that addition is routed in the block diagram.

The third and final item is a group of five triangles, all of which are labeled (b0/b1/b2/-a1/-a2). If you take a look at the output of the filtergraph~ object as you manipulate the graphic interface, you’ll notice that the left outlet sends a list of five numbers as its output:

If you’ve looked at the input labels for the filtercoeff~ object, you’ll notice that there are also 5 outputs sent to the right 5 inlets of the biquad~ object.

Each of those five labeled triangles correspond to the parameters we use as multipliers to configure the biquad~ object to respond as the kind of filter we want. We can use the gen~ param operator to represent them.

So we know what gen~ operators we’ll use to patch our biquad filter, but how are they hooked together?

I’m going to show you a really simple and elegant way to help you translate this filter diagram to a gen~ patcher. I learned it from Jon Christopher Nelson, who gave a workshop on physical modeling using gen~ that I attended. I hope it’s as great a help to you as it has been for me.

Jon did something interesting when it came time to do his patching: he took the block diagram you see above, and he rotated it 90 degrees, and redrew the labels. Here’s the result:

For me, that simple transformation suddenly oriented the diagram so that the information flowed from top to bottom… like the ordinary Max patching I do all the time. To this day, I’m a little embarrassed and fascinated about why that made understanding things so much clearer to me, but it’s true. I started by laying out the history, param, and + operators in a way that corresponded to my block diagram, and then started thinking about their interconnection.

I’m going to point something out to you that I didn’t notice at first when I started creating this patch. Yes, that’s right. I completed what I thought was a version of the patch and it promptly blew up as soon as I turned the audio on. It was a simple thing error that it took me a couple of minutes to find, and it's also the error in the block diagram in the coefficients tab of the biquad~ object's help file:

Take a look at the labels for a1 and a2 in the block diagram. Notice the minus sign preceding them? I didn’t notice it the first time around. That parameter is a negative number, which means that adding a negative number is actually subtracting that value.

The other part of my patch conversion was connected to noticing that all of those + operators in a row were actually summing the results, which meant that I could replace those three + operators with a single – (minus) operator and take advantage of the fact that multiple inputs to the inlet of any gen~ + or – operator are summed. The outputs of param operators b0, b1, and b2 are all connected to the left inlet of a – operator, and the outputs of param operators a1 and a2 are summed by their connection to the right inlet of the – operator. Neat trick, eh?

Finally - having blown up my filter after making a mistake with the patching, I decided that I might save my ears and my speakers by the simple act of adding a clip operator to my patch at the very end to slip the output to a friendlier output range of -1 to 1. It's a good thing to add to any gen~ patch, actually — for me, anyway.

Once I’d sussed that out, it was just a matter of connecting the operators to one another as shown in my block diagram. Here’s what I wound up with:

It was time to test out my port of the block diagram. I grabbed a copy of the biquad~ help file and modified it so that the parameter messages matched my patch, plugged my gen~ patch in where the biquad~ object should be, and turned on the audio....

Success (pause for a well-deserved celebratory libation and a bad imitation of Zorba the Greek dancing….)! 

Now that I’ve got a working filter I built from a block diagram, let’s compare it to the biquad filter contained in the Gen examples folder (gen~.biquad.maxpat)

That wasn't so hard, was it? Okay - here's an example you can try turning to a gen~ patch yourself. It's a variation of the standard biquad filter with a little different topology:

See if you can do the "rotate and replace" trick and create your own gen~ version [remember to keep an eye on those a and b labels and watch out for minus signs!].

...and no peeking until you've taken a run at it. The biquad_exercise.maxpat patcher in the patches folder contains a solution to the problem.

We're on a roll, so let's try a little more complex example. Like the biquad filter, this block diagram describes an example of a delay-based effect that can be produce varied output (vibrato, flanger, chorus, and doubling) based on how its input parameters are set. This bit of digital signal processing was first described in this paper by Jon Dattorro (whose name you may know from the Dattorro reverb). Here's what it looks like, and we've included a listing of how the inputs can be varied to produce different output effects:

Although you may never have seen this bit of patching before, you may have heard it. This patch forms the basis of the original Pluggo Generic Effect plug-in, which has also been ported to Max for Live as a part of the Pluggo series (the Max for Live device shares a common ancestor with the above patch, but is implemented differently).

Okay. Let's start by doing our "rotate the block diagram" trick and looking at what we have in terms of top-to-bottom signal flow:

With one exception, this block diagram is pretty easy, now that we know how to translate the triangles and the "cross in a circle" blocks: each triangle is a param operator, and each circle is replaced by a + operator.
But what about the Z^(-N+M) box — how might we patch it? As I mentioned earlier, Z^(-N) refers to a delay value which may be greater than the single sample delay we used the history operator to represent. Our other hint comes from the input to the block in the diagram labeled modulator. 

Let's look at the settings associated with various effects again:

Instead of working with single sample delays, we will be using a standard gen~ delay operator with two taps (outputs) One of them will be a delay time in samples (the Delay column in the original block diagram) set as a fixed number of samples. That number of samples to delay our input by will be altered further by adding a value in samples that is derived from a modulated sine wave whose output is scaled to a specific range in samples (described in the Modulator column).

Our delay module in the block diagram is outputting two different delay values - the fixed delay value (the Z^(-N) portion of what happens in the delay block) is used for Feedback (the FB column in the original block diagram), which the summed fixed delay and modulated delay value are sent on be scaled by the Feedforward control (the FF column in the original block diagram).

Here's what the result looks like - for the sake of ease of reading, I've outlined the Z^(-N+M) portion of the block diagram. The feedback (FB), feedforward (FF) and blend (BL) portions of the gen~ patch are simple substitutions and summing operations. The delay portion of our block diagram takes the -N and M values in milliseconds in the tables, but those need to be translated to a number of samples at the current MSP's current sample rate. The mstosamps operator handles that for us in both cases.

To manage the delay, we're using a 2-tap delay (set by the second argument to the delay operator). The left output of the delay operator outputs the fixed sample delay value for the feedback calculation and summing (set by the value sent to the in 2 operator. The right inlet's value (in samples) is derived by summing the fixed delay input and whatever the current sample count from our sine function is sent to the in 3 operator.

It's really not that difficult to figure out, once you get the hang of it.

The dattorro_effects.maxpat patch provides you with an example to play with that also includes a lovely way to deal with modulating the input to that third inlet to the gen~ object (especially useful for those chorus and doubling effects), courtesy of our friend and benefactor Jon Christopher Nelson. The jons_cool_modulation patcher lets you set frequency and amplitude for the modulating sine function, but also to set a degree of randomness to the output that smoothly transitions from setting to setting. It's worth a little careful study.

There are several other places where DSP programming uses block diagrams for explanation/demonstration. 
Here are a couple of links you can use to begin your explorations:

As you explore these techniques and go off in search of block diagrams you might like to try implementing in gen~, I’ve got a few suggestions you might want to keep in mind.

I've discovered along the way that it's often not enough to just copy a block diagram and start patching from there. Part of my frustrations wind up stemming from a simple observation: block diagrams for filter design are often meant to provide conceptual models rather than a starting point for implementation. 

One obvious place you may notice this is a situation where you realize that your block diagram has absolutely no delay for feedback — that's simply not possible in the digital world (a caveat: Some filter algorithms can be rearranged to have better frequency or phase response, while preserving 0 delay in the main path through. The trapezoidal SVF is an example of one of those).

Here's a real-world example of this from the Max Forum: In this thread, the paper showed a diagram of what a circuit should conceptually be, and then the text explained how this is impossible due to zero delay feedback. If you read on, you'll find how they solve the zero delay feedback problem by re-arranging the math. 

You may also find — particularly in the case of academic papers — that there'll be another kind of error in the diagram that's corrected in the text of the paper. These aren't things that happen all the time, but it never hurts to read to the end of the paper you're grabbing your block diagram from (ask me how I know this....).

It's also sometimes the case that the way that someone characteristically describes signal flow in a block diagram isn't actually the way that most people do the calculation — the amazing and wonderful Waveguides website describes and example of that pretty succinctly in their section on Implementation Details, for example.

That said, there are a few block diagram labels you're likely to encounter that don't need to scare you off at all. Blocks in a diagram that correspond to filters can easily be substituted by grabbing examples of those filters from the gen~.filters.maxpat examples file and just dropping it in, along with some param operators, for example. Here are a few others:

From time to time, you’re likely to see a Greek letter sigma (∑) in a part of the block diagram. Here's an example of it taken from a block diagram you might even recognize - it's that same generalized effects block diagram we just worked with (in fact, it's the illustration the author himself uses in his paper on the subject):

Since you're familiar with the block diagram you just worked with, you'll probably notice right away that it’s the same position as the the + operator substitution we made for the “plus sign in the circle” in our previous examples. You can just substitute the + operator whenever you see a sigma like that and you’ll be fine.

One of the other symbols you're likely to run across is the Integral symbol ( ∫ ). That can be a tricky one to encounter, since it might mean a simple integrator (which would be a simple substitution using the += operator), but it might also mean that you need  a "leaky integrator" (would would be a history operator, a + operator, and a * operator for the leak factor). It’s not always easy to trust the diagrams, and you may need to go beyond the block diagram into the text to figure out what you need.

Learning To Block With The Problems You Tackle

As you experiment with building filters, you may find something interesting related to looping delay lines. You'll probably find yourself in a situation where the output of your filter vanishes when you crank up the feedback. It's not you - there's a name for what's happening: DC offset. 

It happens as a result of averaging process — very slight positive or negative average offsets get amplified inside the loop until the signal gets messed up. In the filtering world, the usual solution is to add a 30Hz. highpass filter into the loop. The dcblock operator in gen~ is a simple solution that handles that for you without the need to copy and paste 30Hz. highpass filters into your patch.

I hope this has helped to demystify those block diagrams for those of you starting out with your gen~ programming.

By the way, writing this article reminded me once again of the amazing workshop that Jon Christopher Nelson presented at a previous SEAMUS conference. I got in touch with him to thank him once again for his patch rotation hack, and asked if he'd be willing to submit his physical modeling gen~ patches as a Max Package Manager submission. The good news is that he said, "Yes!" 

So keep your eyes peeled for its appearance in the Package Manager. It's a great example of "content you need."

biquad_block.jpg

 This tutorial will show a couple of simple examples of filters implemented in gen~ along with a neat trick that may help to make sense of using block diagrams when patching.

a-walk-around-the-block-an-introduction-to-gen~-and-filtering

A Walk Around the Block - An Introduction to gen~ and filtering

I’m not sure why, but it seems like lots of beginning Max users think that the only way to do anything cool with Max includes hours of meditation and days of careful patching. While that’s sometimes true, there are a lot of useful and entertaining things you can come up with on a grey and rainy afternoon. Often, it starts with just playing around and having fun, combined with the kind of basic background understanding of how Max works that a little quality tutorial time will give you. 

Here’s a rainy-day afternoon hack that sounds a lot more complicated than it was to do. It all began with playing around with an old favorite Max patch of mine – Forbidden Planet.


The patch has been around a long, long time as an example of how to do convolution filtering in MSP using the pfft~ object – it was even turned into a Pluggo plug-in back in the day. The current version of the original Convolution Brothers patch has been further hacked into the pfft~ form we have today by Richard Dudas (Or xoax, as he is known among Max afficianados. You owe him a drink, at the very least).

The idea behind the original patch is simple and elegant: using a multislider object, you can draw a contour for a 512-step convolution filter which gets applied to your input. It’s a lot of fun (I’ve included a copy of the patch and the abstraction the pfft~ object needs - fp_fft.maxpat in the download package).

I was drawing filter curves to compete with the sound of the rain outside my window when I suddenly thought to myself “There’s no real reason that I have to be the one drawing those filter curves. What if…”

In these moments, I tend follow the “What if…” question by running through my usual approaches to generating and organizing variety – stuff like using random values or a drunkard’s walk to generate the list of values, using LFO outputs to write the list of input values (as I tend to love to do), and that sort of thing. In this case, I started to wonder about using Jitter as a source.

Jitter is great at creating and processing images, but it’s also useful because it works with matrices – large batches of data that represent the frames of the image being displayed, the OpenGL object you’re working with, and so on. In the case of visual images, each pixel in the movie contains 4 planes of data in the range 0-255 and is part of one big array – an array you can slice up in various ways to generate lists of data you can do other things with.

So I thought, “I wonder what I’ll get if I slice up a video image and grab a scanline and use it to fill the multislider? If I can do that, I don’t need to modify the Forbidden Planet patch’s innards at all. It should just work and maybe do something cool with little effort on my part."

(Author’s note: since I’m writing a more-or-less tutorial, what you read next not only condenses the time I spent playing around and checking the refpages – it also leaves out some other great ideas that came from just playing around and having fun. I won’t go into them here, but I just wanted to remind you how important fooling around and having fun can be.)

I added a playlist object to my Forbidden Planet patch, and then clicked and dragged to load a movie (I went with dishes.mov), and clicked on the circular button to enable looping of my movie. A jit.pwindow let me keep track of what I had as I worked. I was working with a video, so I knew I had a 4-plane matrix full of char data.  What I needed was what the Forbidden Planet patch’s multislider contained: a single list of 512 floating-point numbers in the range 0. - 1.0. 

Broken down into pieces, here’s what the problem looked like:

Take that 4-plane char matrix “slice” and convert it into a single-plane matrix that contains 512 items, each of which is a floating-point number in the range the multislider object in the Forbidden Planet patch uses.

I’m breaking this down because lots of folks out there who are interested in converting images to data (that process of to-from or from-to has the fancy term transcoding) do this a lot, which means that this is a good thing to learn to do, and a useful skill to have. As is often the case in Max, there are a number of ways to do this; I’ll show you what I think is a quick and easy way:

To create the horizontal slice from the original image, I’ll use the jit.submatrix object, created to do exactly that. The object uses attributes (@dim and @offset) to define how you want to slice things up (the example below shows you what the output looks like)

I only need a single plane for my list. Instead of using jit.unpack and deciding which color plane to use, I’ll keep it simple: the jit.rgbluma object will output a 4-plane matrix where each plane contains the same information: a monochrome image.

What might seem to a beginner to be the trickiest thing to do – changing the number of entries in the matrix and converting the data from the char range (0-255) to floating point numbers (float32) is made simple by virtue of a feature of jitter matrices: they adapt. If you specify different attributes when you create a jit.matrix object and send it a matrix whose attributes are different, the receiving jit.matrix object will automatically adapt by changing the dimensions of the matrix and number of planes, as well as scaling the incoming matrix and converting the values.

After that, all that’s left to do is use a jit.spill object to convert the matrix to a list of values to sent the Forbidden Planet’s multislider object.

To keep things compact, I removed the jit.pwindow objects and connected the jit.spill object to the multislider in my original patch, which suddenly started making much more interesting noises.

Putting it all together (and taking it apart again)

My rainy day patch sounded kind of cool as it was. One of the great things about being able to reuse patches such as the Forbidden Planet is that you’re done quickly, and have more time to think about improvements.

While my patch sounded great, I was thinking that it would be awesome to have a stereo version. The lazy (or efficient? You decide!) way would be to just duplicate the pfft~ object and hook everything up again….

But I was thinking that I’d like to look inside and examine the patch loaded by the pfft~ object. How hard would it actually be to create a stereo version? Here’s what I found:

The inside of the patch wasn’t scary at all! I had a single-channel buffer~ object (EQFun~) that had list values unpacked by a listfunnel object and written into the buffer using using a peek~ object. The EQFun~ object was connected to the third outlet of the fftin~ object, which a quick look at the refpage explained output the frame index for the FFT.

So – all I’d really need to do would be to have a second fftin~/fftout~ object pair for the right channel of my pfft~, together with a second buffer~ that I could use for getting index values. 

Wait… the EQFun~ buffer has only one channel. Why couldn’t I replace it with a stereoEQFun~ buffer and then both write the incoming list data to one of the channels and then have the peek~ object use one of the two channels to do the indexing? That ought to work fine.

And it did. Here’s what the new abstraction (called stereo_fp_fft.maxpat) looks like now:

I had two more ideas from my Jitter life that I thought I might try, too.

The horizontal slice I created was the very top of the video image (@offset 0 0). Since attributes work as messages to Jitter objects, I could send the message offset (number) 0 and grab any horizontal line in the video – all I’d need to do was to add a message bpx with the contents offset $1 0 connected to a number box and then send that to my jit.submatrix object!

I love smearing video images using the jit.slide object (okay, I’m actually doing cellwise temporal envelope following, but I think it looks smeary) and using the messages slide_up and slide_down for different effects. There’s no reason I can’t do that with the matrix that contains my list of values before I unroll it and sent it to the multislider….

So I spent a few minutes prototyping it and it worked like a charm - I could scan back and forth through the movie, and produce subtle, almost vocoded effects. And the fact that I was now working in stereo meant that separate channels could have separate controls, as well – setting the offset for each channel to near neighbors produced really subtle effects. After my proof-of-concept messing around, I rolled both of these things up in a nice subpatcher that kept things neat and tidy:

The result? Not at all bad for a rainy afternoon. I hope you enjoy these patches, and feel free to make your own improvements. Happy patching!


rainy-day-max-return-to-the-forbidden-planet

Rainy Day Max: Return to the Forbidden Planet

dan derks

Even though my background is largely in theatre, I've always been interested in math. To me, theatre is about digging into the subjectivity of truth, but math always felt like an effort to objectivize. There is still poetry in it, though -- as a kid, geometry particularly felt like a balanced carrier for head and heart.

As I became more interested in music, I found that things felt best when my creative process had the same head/heart balance. Too often, I found that the more I exercised will and control (as if I was somehow going to compose a never-before-heard melody), the less healing music became. Infusing ego stripped the fundamental experience that making music naturally provides -- the one which rewards curiosity and makes you feel happily small against the full scope of nature.

It's funny how many breadcrumbs are scattered through the landscape of open source music technology. A bit of code can act very much like a score -- it is not only an individual expression of an idea , but it encapsulates the possibilities of that idea. It's both an expression of self,  like any piece of art, and a tool that can be repurposed, remixed, and reframed to fit the unique needs of a wide range of artists.

Ezra Buchla's implementation of 1-d cellular automata for monome's Teletype has been one of the most impactful bits of code for me. At its core, it's a simple adaptation of the elementary cellular automata initially described by Stephen Wolfram in his groundbreaking book A New Kind of Science.

The celllular automata start with a fixed set of combinations:

[111] [110] [101] [100] [011] [010] [001] [000]

Search Results