Les Stuck

The trigger object is a humble but profoundly useful Max object. It doesn't make amazing sounds or images, but it will keep you sane while you do.

Let's say you have a working patch. You decide that its layout could be a little clearer, so you start moving things around - not changing any patch cords, just moving objects. Then, it doesn't work! This can happen because when an object's outlet goes to more than one destination object, the order of those messages is determined by the position of the destination objects. Layout matters.

Look at the print object outputs in the Max window to see how moving the print objects changes the message order. That can really mess things up in a complex patch. To bring some law and order to this Wild West of a patch, just type “trigger bang bang bang” into a Max object box. Or, if you’re not feeling all King of the Cowboys, you just can abbreviate with “t b b b”. 

The patch now works, no matter how much you move things around. Sanity!

The trigger object not only works with bang messages, but with all Max data types. Each argument (b, i, f, l, s) specifies a data type (bang, integer, float, list, symbol) and results in an outlet. Not only that, trigger converts messages from one message type to another. So, each type argument results in an outlet of that type and each incoming message produces a message of that type out of the corresponding outlet.

Changing the type of a a message can be tricky, but there’s usually some logic to it. For starters, any message of any type will result in a bang coming out of a “b” outlet. And if you send the trigger object a float, any “i” outlets you have created will output the number with the floating part truncated (e.g., 3.14159 becomes 3). If you input a list that begins with a number, trigger will output the first number only, retyped if necessary, out of both the “i” and “f” outlets.

Here’s a very common use for the trigger object’s order-forcing and type conversion:

When calculating a result from two numbers, it is normally the case that only the left inlet (or hot inlet) will produce an output. If you want the calculation to happen for either input, you’ll need a trigger object. Use “t b f” to set the right inlet, then send a bang message to the left inlet.

Unfortunately, there are some type conversions that aren’t as obvious. Sending a bang message results in a zero from the integer and float outlets. A symbol (a text string) emerges unmodified from the list outlet, as does a list out the symbol outlet. But an integer or float seems to produce no output at all from a symbol outlet. 

What's going on? Well, actually it outputs a message consisting of the null symbol “” - the most Zen of all Max messages. The null message clears the message box and it can trigger a button object, but it doesn’t do anything particularly useful.

Important Hint: “t l” will pass anything unchanged! You can use it to group all kinds of messages together to help declutter your patch. And one more thing: you can use any number or unreserved word as a “constant” argument. The trigger object will output that number or symbol regardless of the incoming message.

It’s not a bad idea to use a trigger object anytime an object has more than one patch cord coming from a single outlet. In fact, if your patch is complicated, adding a trigger object at the top can be a way to define the main components in an orderly way. If you change your mind later – if you need to add one more process at the end, for example – you can just type in the new argument. After that (noticing the updated outlet assistance), use option-drag (alt-drag on Windows) to select all the patch cords to the right, then drag them to the right so that the outlets line up again:

We noted above that “t l” passes any message. That also goes for pointers such as those that refer to Jitter matrices (e.g. jit_matrix u464001211) and or GL textures (e.g. jit_gl_texture u471000910). Since these messages are just symbols, using the trigger object for openGL textures doesn't result in reading back from the GPU to the CPU, so you can use trigger objects freely to organize your texture processing.

If, like me, you’re totally in love with the trigger object, and if, like me, you know a tiny bit of JavaScript, then you’re ready to explore the jstrigger object in Ben Bracken’s recent article. Trigger warning: it’s fun.

Learn More: See all the articles in this series 


my-favorite-object-trigger

My Favorite Object: trigger

Cory Metcalf

Several years ago, Darwin Grosse and I worked on a project that used optical flow to track people running around in circles to simulate the jog wheel on old analog video tape decks. As is often the case with many sensor projects, the raw data was really jumpy and jittery and required some serious sweetening and massaging. Darwin’s solution, much to my surprise, was the bucket object. It’s been a valuable tool in my Max swiss army knife ever since. 

Download the patches and abstractions used in this tutorial.

The bucket patch I use the most allows you to get a running average over some finite set of events (if you want a running average for an stream or unspecified set of values, you'd use the mean object). Here's an example that calculates the average of the last 8 floating point input values:

This technique is really useful, but can be a lot to patch when averaging a larger value set. The included bucket.avg abstraction included with the downloadable patches lets you type in the number of values you want to average and scripts the connections for you. Keep in mind that the zl sum object will default to a maximum list length of 256, so if you want a larger value, you’ll have to alter the zl object.

Here's the patch in action (make sure you have the bucket.avg abstraction in your search path):

The bucket object is also computationally useful for calculating first and second derivatives for streams of data. The terms "first and second derivative" are math-speak for keeping track of:

the rate that things are changing (that's what velocity is - the rate of change in a value over time.)


the rate at which the rate that things is changing - that's what acceleration (the second derivative) is.


The bucket object is a little unusual in that you don't need to worry about using arguments to the object in order to have it work with floating point values. In fact, bucket is so useful that people often ask whether or not there's a Max object that is similar but will work with symbols or lists. While there isn't a specific object that works with symbols the way bucket does with numbers, here's a Max patch that does exactly that (and it helpfully outputs stuff in standard right-to-left order, too):

As with the first example, this can mean a lot of patching when you start making one for larger lists. The bucket.sym abstraction makes easy work of this - just type in the number of outlets you want as an argument (i.e., bucket.sym 4).

I hope you can see how I’ve come to rely on the bucket object, and how it has influenced me to make similar tools for other message types. If you have other uses for the bucket object, please jump onto the forum and share!

Check out the entire "My Favorite Object" series: bucket, stutter~, jstrigger, multislider, plot~, trigger, rate~, jit.slide, curve~, jit.gl.mesh, button, jit.gl.pix.

Learn More: See all the articles in this series 

my-favorite-object-bucket

My Favorite Object: bucket

Timothy Place

For this edition of the “My Favorite Object” series, I’m going to walk you through plot~, a Max data visualization object. In my 16-minute video, I’ll go from help files to how to set up amazing graphic filter displays. Join me and you’ll see why I love the plot~ object!

Tim Place provides an overview of his favorite object called plot~, a Max data visualization object.

My Favorite Object: plot~

my-favorite-object-plot

Andrew Pask

I used to think the classic stutter DJ effect was one of the trademark sounds of Pluggo. No doubt it has been around a lot longer than that, and maybe even in acoustic music somehow. But about the time I started going along to gigs and hearing people use it (all over the place) I found out that there was a Pluggo plug-in called “Stutterer” that pretty much does it all. That plugin survives to this day as a Max for Live device.

Like all sounds which come and go into and out of people’s lives, there is a standard life cycle in play:

Phase 1 (Spotted in the wild): “Oh my god, that sounds so awesome! What is it?”

Phase 2 (Acquisition): “Aha! Now I have this awesome cool trick that NOBODY ELSE knows about, and I’m going to slather it on everything.”

Phase 3 (Disillusion): “Ugh, it’s all over everything. I need to get rid of this crap. I’m sick of it.”

Phase 4 (Reconciliation): “Hmm... Yeah - mixing it in very subtly every now and then and changing it around a lot can be pretty effective”

I never went through this with the stutter effect much, because I never really liked the stutter effect itself. But I did look at how it was made, and I found a new use for the object which was built in MSP to do this.

And so, allow me to present the stutter~ object.

If you look at the help file for the stutter~ object, you can discern its primary function as a stuttering engine. Turn off auto grab and make the grab size larger. Now you can bang on the playback speed and bang the stutter~ object to copy the grab size to the playback buffer and cycle through it

The stutter~ object implements a ring buffer and writes audio history to it. In other words, it always holds the last  number of samples in memory, and is constantly updating it, so the oldest sample in grain size is dropped when the newest sample is added. When you trigger it by banging it or sending it a number of samples to grab, it copies that number of samples over to another buffer and makes them available for playback. You can also tell it to copy the samples over to an external buffer~ or polybuffer~ in your patcher.

So it’s like a little musical memory. What I then did was start chucking huge numbers at grain size. What if it could remember the last 10 seconds?

Once you start doing this, you’ll need to give the stutter~ object more memory to use. Typically I’ll have it set up like this:

So this means I am telling the stutter~ object to have a maximum size of 500000 samples, start with a default grain size of 11025 samples (250ms @44.1k), invert trigger polarity, and copy 256 samples per perform loop over to the playback buffer. This last arg might seem to be a bit strange - what the hell is a perform loop?

Without going into a bunch of arcane MSP external detail, let’s just say this object is OLD. You need to tell it to up its game in the performance department if it is going to keep up with you moving larger chunks of audio around.

To get started, download this simple, beat-synced looper patch.

My patcher and favourite use of the stutter~ object uses the global transport to stay in sync with itself and set tempo. I want to be able to grab bits of audio from places and play them back in sync with the rest of my code.

Or not. You can grab any length of time from the stutter~ object.

Here’s how it works - If you choose to grab a number of samples which is an integer multiple of some metrical time element (as measured in samples) and then play it back, it might not be exactly offset in your bar correctly but it will loop perfectly as long as you remain at the same tempo.

If I choose to grab 1 bar of history at 120 bpm with an SR of 44100, then I grab 88200 samples. No matter where in the bar sample 1 is, it will always loop in sync with my bar as long as I do not change the tempo (or the sample rate).

So it’s in sync - I don’t need to worry in the slightest about quantizing the record start or lining everything up with 1 in the bar. The only time I might need to worry about where beat 1 starts is if I wish to  create a “clip” out of my loop, and change the tempo (hint: the groove~ object )

Most people I’ve given this looper to don’t like the fact that it seems to work in reverse. The way I have presented it is that you do not start “recording” a loop into it - rather, you wait until you have played something and then copy it from history. Personally I find this more interesting in performance. It means I always have the ability to grab something which happened rather than consciously setting up the grab or missing things that go by because I didn’t hit the record button.

You can make the patcher act as a more typical looper by delaying the grab. So if I want to “start recording” a 2 bar loop, I delay grabbing the loop from history until 2 bars have passed. Again, accuracy doesn’t matter when it comes to the exact timing of things, as long as you copy a “metrical” amount of samples it will stay in sync.

Here are some other things you can do with this - I'll leave them as an exercise for the reader.

Set it up to work with polybuffer~ so you can catch multiple loops and layer/arrange them.


Add ramps to the playback stage so you can de-click.


Implement pitch and time on the playback so you can change tempo.


Spread the looper out over multiple MFL devices so you don’t end up saturating an output stage.


my-favorite-object-stutter

My Favorite Object: stutter~

Ashley

Fades are one aspect of audio engineering that I can get overly obsessive about. In my Pro Tools sessions, I custom automate every fade, making sure each automation point is set to the right dB level. For the longest time, I was unsatisfied with the automated fade possibilities in Max - I could easily construct a patch that performed timed fades with a line~ object, but the fades never sounded right since the object outputs linear ramps. Then I discovered the curve~ object which - unlike line~ - produces nonlinear ramps. Depending on which value you set for the “curve parameter,” you can create either exponential or logarithmic curves. 

In the first patch provided, you can see the basic operation of the curve~ object. As with the line~ object, you send the object a message that specifies the starting point, the ending point, and how long it should take to get there. However, unlike line~, there's a third inlet where you can set the curve parameter. Values from 0. to 1.0 will produce an exponential curve, and values from -1.0 to 0. will produce a logarithmic curve. At a value of 0., the curve will be a straight line. The farther away the value is from 0., the steeper the curve will be. Try setting the curve parameter to different values and hear what happens.

The second part of this patch illustrates how to set the curve parameter within a message, so you don't need to use the third inlet. This can be very helpful if you want to create an automated fade that uses different curves for the fade in and fade out. In the example provided, the sound starts at an amplitude of 0, fades up to full volume (1) over five seconds using an exponential curve, remains at full volume for two seconds (this is specified by the volume level staying the same and the curve set to 0.), then fades out over one second using a steep logarithmic curve. You can automate some pretty dynamic series of fades using this method. 

What if you want to create a crossfade? Easy - simply create two curve~ objects whose messages are banged with the same button. One curve~ object should be connected to the first sound, and the other to the second. The only possibly tricky part of this is that you have to make sure the timing adds up in each message (i.e. the total time in each message should be the same), and you have to set your curve parameters correctly. 

Patch #2 contains a few examples of classic crossfades you can create. This patch is not hooked up to audio - it's only used for visualizing the fades. If you want to use these examples for audio purposes, you will not need the trigger object or the bufferwrite subpatch - these again are only used for visualization. 

The first example is of a linear crossfade, which uses a curve parameter of 0. This is, of course, the least interesting example, since you can do the same thing with a line~ object. 

The second example is of an equal power crossfade, which is probably one of the most commonly used since it maintains a consistent perceived volume level. If you look at the messages controlling the fade, you'll notice that the curves are mirror images of each other, as in the linear crossfade. What makes this example different has to do with the curves we specify in the messages. This fade has a logarithmic curve (0.5) on the fade out and an exponential curve (-0.5) on the fade in.

To see how you would program an equal power crossfade between two sounds, take a look at patch #3. In this patch, I automated it so that sound #1 (on the left) fades up first, then crossfades with sound #2, which fades out a few seconds later.

The third example is of an S-curve crossfade. Since an S-curve contains two different curves in the same line, you have to specify the time at which the curve should change. So on the fade out, sound #1 goes to an amplitude level of 0.5 in one second with an exponential curve, then to 0 in one second with a logarithmic curve.

Finally, for those of you who would rather draw your own custom fades instead of defining them with a string of numbers, you can use the function object in conjunction with curve~. Patch #4 shows you how this works. Make sure to set the mode of the function object to “Curve.” Now, once points are entered on the function graph, you can adjust the curve between each point using your mouse by pressing and holding the Option key (Mac) or the right-hand mouse key (Windows). 

While all of these examples only use the curve~ object as a tool for audio fades, you can use this object for other purposes as well. The next time you find yourself in a situation where you would like to control the ramp of something at audio rate, hook up a curve~ object and see what happens! 

image3.png

I custom automate fades, making sure each automation point is set to the right dB level. Discovering the MSP curve~ object was a real epiphany for me - I could easily construct a patch that performed timed fades that weren’t linear any longer

my-favorite-object-curve~-1

My Favorite Object: curve~

Gregory Taylor

It’s my turn to talk about “my favorite Max object,” and there’s a problem.

Two problems, really. First, I’m not sure I have a single favorite object – when I look at my patches over the years, it’s true that I have tended to stick with a few objects as the go-to for solutions (trigger, svf~, the multislider, the matrixctrl object), but those are my bros - the noisy, hip, high visibility d00dz in my Rat Pack. What if my real favorite is quiet and humble rather than something that graces every UI I make?

Over the months, my colleagues have also weighed in with articles about objects that I probably would have written about myself – so you don’t need to hear about them again. I’ve also been thinking recently that perhaps my favorite max objects come in pairs rather than being solo performers - using a >=~ .5 and edge~ object pair to convert phasor~ output to a nice bang message, for example. It was the contemplation of that very pair that led me to the subject of this “Favorite Object” post – a humble MSP object that can do nothing by itself, but is capable of great things in the right company: rate~.

Download the patch used in this tutorial.

The rate~ object is mute as a stone when not in the presence of a signal input in the range of 0. – 1.0. But feed it the output of a phasor~ object, and the rate~ object will helpfully time-scale the output of your phasor~ by an amount set by an argument, numbers or signal-rate input. A rate~ object with an argument of 2 will produce a ramp from 0. To 1.0 at half the rate of time as the original ramp. Similarly, A rate~ object with an argument of .5 will produce a ramp from 0. To 1.0 at twice the rate of time as the original ramp.

The following patch demonstrates a classic example of the rate~ object at work – creating the kind of clock multipliers and dividers you or your friends have in your analog rack. To translate the output of a phasor~ or rate~ object, all we need to do is add a pair of Max objects: >=~ 0.5 and edge~. Used together, they’ll generate a bang message at the start of the ramp (from the phasor~ or the rate~ objects).


You can see how the rate~ object makes things simple – feed an integer (for clock multiplication) or its reciprocal (derived using the !/ object) to a rate~ object and you can derive multiple useful bang messages from a single phasor~ input.

Although the rate~ object is used with MSP objects that are ITM-aware (e.g. the master phasor~, the rate~ object itself is not. That’s no problem at if you’re interested in taking phasor~ rates that correspond to notes (2n 4nd, 16nt, etc.) and using rate~ to act as a multiplier, but it may also be useful to use ITM values to set the rate~ object.

To do that, we use the MSP translate object – the Swiss Army Knife of MSP format conversion.  A quick way to do this is to translate a note value to its equivalent in Hz. At the current tempo, and then take the reciprocal of that number as the argument to the rate~ object.


You can use the output of the rate~ object anywhere the output of a phasor~ object can be used as signal-rate input (groove~ and 2d.wave~ come to mind as interesting possibilities right away), but I’d like to show you a few things that I use the rate~ object for besides those: Using the rate~ object as a complex control signal generator.

I think I happened on the practice of doing this entirely by accident. I happened to hook up the output of a phasor~ object to the right inlet of the rate~ object (which accepts signal-rate values as inputs in addition to the ints and floats I’d been using). The results were amazing – the degree to which the output of my phasor~ was being scaled was being changed on the fly, which made the input phasor~ output kind of crumple up at the start.

It was cool. And – of course – I could use tempo-locked phasor~ objects as input for predictably crumpled output values. I could also use the output of my phasor~ to both provide input to the rate~ object and as a signal input to the rate~ object at the same time. I could use my phasor~ to control the rate~ object’s scaling input, and then add another rate~ object to that initial phasor~ ramp….

The rest, as they say, is history (or at least a whole evening of fun and experimentation). I had a really interesting way of producing time-varying ramp outputs I could easily control (and whose output I could again scale with the addition of another rate~ object. But then I remembered my trusty click generating <=~/edge~ pair. The result? Interesting expanding and contracting trigger sources.

Further Mischief

Mindful of Brian Eno’s famous Oblique Strategy (Honor thy error as a hidden intention), I thought that there might be other interesting possible unorthodox connections worth exploration with my now not-so-humble rate~ object. 

The next one seems totally obvious in retrospect: If the rate~ object expects to work with a ramp in the range of 0. to 1.0, what would happen if I fed it something other than a linear ramp? I quickly cobbled together a little patcher that took phasor~ input to generate the same standard waveforms I used in my LFO patches, and then used a scale~ -1. 1. 0. 1. object to to rescale the outputs into the 0. – 1. Range, and fed the outputs into a rate~ object. The results were pretty promising. There was some wave folding going on, and using a nice high number for the rate~ object would spread the time out so that I was generating interesting control curves:

I figured I ought to do a little experimenting with ITM-aware values, and so I did a little exploratory patching – I set up a nice ITM-aware phasor~ with rate~-based scaling on its output, and added the ITM variation for choosing the scaling rate of the rate~ object at signal rate.

It turns out that the default behavior of the object is a mode – the lock mode. Up until now, I’d been using a vanilla rate~ object, where any change to rate~ re-syncs its ramp's start to the master phasor~ object's start. Since I was messing around earlier with changing the rate on the fly, I was wondering about what would happen when the original and rate~ object outputs got out of sync. I had my answer. I looks like the cycle mode does the resync by looking at the master phasor~ object’s output whenever the rate~ object finishes it’s work. To investigate a little more, I set up a pair of outputs with different modes, and ran them from the same inputs. The results were pretty astounding:

Fast forward several hours of my listening to scraping noises and generally having a great time.
And finally, I realized that I could create a nice patcher that let me select a waveform (and a multiplier for it, thanks to the rate~ object) at ITM rates and use that as the input to both the master phasor~ and the rate~ object independently.


The possibilities for where to use this are, um… pretty good, as we say in the American Midwest. Just for fun, I’ve hooked that last patch up to an MSP patch that pumps white noise through an svf~ object where all I’m doing is using my wonderfully crumply rate~ object output to control filter cutoffs and resonance (at independent but synchronized rates, thanks to… yeah, that’s right – another pair of rate~ objects.

I hope this gives you an idea of why I’m a big fan of the rate~ object. Happy patching!

zip-and-unzip.jpg

While many of you may be familiar with the rate~ object when paired with the MSP phasor~ object for scaling generated ramp outputs, there is a wealth of hidden wonderfulness that I’d like to show you.

my-favorite-object-rate~

My Favorite Object: rate~

Tom Hall

It’s one of those objects that can slip by you or easily be written off as just a UI object, but it’s so much more than that. I really dig multislider and obsessively so. I should probably use other stuff instead, but I really enjoy a visualization of the data I’m using.

Download the patches used in this tutorial.

For example, I like to use it a a sequencer with another multislider layered over the top that gives you position, real-time dynamic changes with visualization of those changes and positioning. What’s not to like?!

Another way you can use multislider is as a way to visualize and unravel data from a dictionary or a coll. For example, if you have multiple drum patterns or scales set inside coll as simple patterns of zeros and ones, you query coll with a simple number and the list is sent straight out to a multislider giving you a visual of what that looks like.

I have my multislider set to a range of 0.0-1.0. So the pattern in coll results in either steps that are on or off.

These values come out of multislider as a list, or can be queried individually by step and could then be routed to drums, gates or filters.

Additionally, you could use certain patterns as starting points and then go ahead and manipulate them dynamically - (see the [pak 0. 0. 0. 0. 0. 0. 0. 0.] running into the multislider).

Like I said, you could avoid all of this, but if you’re a visually oriented musician that likes to see the data as well, multislider can be a really great object/tool.

my-favorite-object-multislider

My Favorite Object: multislider

Andrew Benson

My favorite object is jit.gl.mesh. It’s a plainspoken object, direct and honest, powerful and decisive. It doesn’t do anything for you without a little effort, but if you can learn to speak its primitive matrix language it will take you far beyond the known territory. I wouldn’t be exaggerating to say it finds its way into every patcher I write, and has become an essential part of how I think in Jitter.

Upon instantiating jit.gl.mesh, you are faced with a bunch of mysteriously named inlets. Fortunately you can safely ignore most of them most of the time, and focus primarily on the position, texcoord, and sometimes the color inputs. In many cases I’ll only use the first position inlet. This is the one that will define your 3D geometry’s shape when you send a Jitter Matrix filled with XYZ coordinates. The second texcoord inlet is often the next in line, and expects a 2-plane matrix to define how a texture is mapped onto the geometry.


Now that we’ve gotten introduced, the work begins, and before we can really get down to business we’ll need to get clear on a few of the ways that jit.gl.mesh expects to be dealt with. First of all, that first inlet of jit.gl.mesh expects to see a 3-plane float32 matrix. If you are using the default draw_mode, it needs a 2-dimensional matrix, while most of the other draw_mode settings expect one dimension (or more). The values in the cells of the matrix will come to represent cartesian coordinates in 3D space. By default, you’re well served to keep the values in the -1. to 1. range roughly if you want your geometry to fit in the viewport with a fixed camera view. The center of window will be (0,0,0).

By default, jit.gl.mesh uses the tri_grid mode to draw the incoming geometry data. This interprets the matrix as a connected mesh of triangles in a grid pattern. Both tri_grid and quad_grid are actually interpreted by the jit.gl.mesh object and converted to simpler geometry before sending along to the graphics hardware.

If you open the included basic_circle patch, you can see a couple of simple geometry generators in use. The first button on the left will generate a flat plane across the XY dimensions. You can switch the poly_mode to get a better view of the underlying geometry, and how the triangle grid is laid out.

For extra credit try connecting a jit.noise to the position inlet of jit.gl.mesh and see how that behaves. Going beyond jamming noise through your patch can get a little tricky, and really isn’t going to make much sense without familiarizing ourselves with OpenGL drawing primitives. 

The important thing to know about this diagram is that - in Jitter - the ordering of points is going across the matrix from left to right. If there is more than one row of cells in the matrix, each row will be interpreted as a separate shape. This can be used to efficiently generate many copies of simple geometry where jit.gl.multiple might be a little slower. To the right of the basic_circle patcher is a circle generator. For the most circle-like results, switch into polygon drawing mode, but you can also experiment with other ones as well. In the case of the simple shapes like triangles, quads, and lines, each primitive shape is generated according to its set number of vertices. So with triangles, every three cells of the matrix across will be a new triangle. Knowing this will help plan when it’s time to generate some shapes using your own jit.gen or jit.expr objects. You can peek inside the jit.gen to see how we're generating the geometry data with a couple of simple math operators.

While jit.gl.mesh is capable of generating every variety of shapes in 3D, I find much of my usage clustering around 2D purposes lately. It’s also nice when getting started with the mesh to restrict yourself to fewer dimensions. By combining position data with texture coordinate data, you can do some really compelling image distortions and effects. I’ve included a couple of patches to play around with one such effect that I use a lot.   The “texture_fun” patch shows the basic idea, generating a few 2D polygons that map to the screen and are textured with a video input, with controls to move that geometry around and shift the texture mapping as well. 

The second patch, “texture_fun_more” shows the same configuration but with the addition of feedback using jit.gl.node.

If you’re curious to learn more about jit.gl.mesh and OpenGL in Jitter, I highly recommend the Video and Graphics tutorial set in the Max documentation and digging into the Jitter Recipes online. Happy Patching!

meshgraphics1.png

 My favorite object is jit.gl.mesh. I wouldn’t be exaggerating to say it finds its way into every patcher I write, and has become an essential part of how I think in Jitter. 

my-favorite-object-jit·gl·mesh-1

My Favorite Object: jit.gl.mesh

Ben Bracken

I’m a huge fan of using Javascript in Max via the js and jsui objects. It provides a fairly comprehensive tool set for patcher scripting and more programmatic approaches to certain Max tasks, all in the familiar wrapper of Javascript. Along with Javascript comes an API that provides number of very useful features, such as text manipulation, array usage, dates, and regular expressions. These days, a lot of these are bundled elsewhere in Max objects, but there are still instances when using Javascript is a much cleaner approach.

But, when you want to utilize a very specific Javascript feature in a streamlined way, making a new js object, opening its text editor, saving a text file, and then hooking the object up feels like a few too many steps. This is where the jstrigger object comes in handy.

Granted, the object isn’t going to solve all of your problems, but I’ve found it incredibly useful for doing things that would otherwise be cumbersome with other objects or to avoid the somewhat drawn out process that is required for setting up a new js object and script.

The basic concept of the object is that it can be used like a trigger object, but with the twist of being able to perform different Javascript instructions on the incoming data for each outlet:

Each parentheses pair describes an outlet, and whatever is within that parentheses specifies how the data is evaluated and processed. In this example, we have three different instructions, output each to different outlets - this is an exceptionally simple example, and only hints at the true potential of the object.

Digging a little deeper, and starting to lean on the Javascript API a bit more, let’s look at some of the possibilities with the Javascript Math Object. I’m always wanting to generate random float numbers. There are numerous ways to do this in regular Max (random->multiply by a float, float32 jit.noise->jit.spill, etc) but it’s always just a few too many steps for me, so I use jstrigger:

It’s one stop shopping! The whole statement is in parentheses, to let the object know where to begin parsing, and we are utilizing the random function of Javascript’s Math object. Of course, we might not always want our random float value to be between 0. and 1., so we can easily add a range, using an array-style reference to what is coming into the object:

The ‘a’ refers to the incoming list, and the [0] and [1] refer to the position of a value in the list. The first value is a min and the second value is a max

You can make this as complicated as you want, adding various other Math functions or logic to fine-tune to your specific needs. It all happens in one box, so it is very portable and fairly easy to read. Here is an example of prepending a string to the output:

I’m simply making an array out of the entire statement, with the first entry being my ‘freq’ string, and the second entry being the random value.

Most any of the global Math functions will work in this manner. For a list, check out MDN.

Max already has the rexexp object, which is reasonably easy to use. But if you are more comfortable with Javascript, and you have a simple one-liner, why not use jstrigger?

Here is a simple example that removes spaces from incoming data:

Again, we treat the incoming text like the first element of the array, a[0], and then use the replace() function to look for the spaces (s), and then replace them with nothing (‘’).

Another feature that I love is the ability to use conditional operators as shorthand for if statements:

Conditional (or ternary) operators evaluate a condition that return ‘true’ or ‘false’ (does the input match ‘bob’?), and then returns an expression based on what is returned. In this case, if it (a[0] == ‘bob’) is true, “bob has entered” is returned, and if it is not, “someone else has entered” is returned.  

I’m just scratching the surface here, as you could do a whole lot more, but hopefully this at least shines a light on a dimly lit corner of Max that you might find useful in your patching. Enjoy!

my-favorite-object-jstrigger-2

My Favorite Object: jstrigger

When I began working in video – after learning the basics of lighting, camera, and editing – I became fascinated by compositing and special effects. This was ten years ago, back when most of this sort of thing was done in 2D. At the time, one of the most powerful compositing and effects applications was Shake, so I studied it extensively. It was node-based, like Jitter, but non-real-time. A couple of years after Shake was discontinued, the jit.gl.pix object appeared, offering real-time node-based programming of 2D video–all done on the GPU! It quickly became my favorite object.

It’s not really a single object; it’s a special kind of Gen patcher environment for processing openGL textures which includes about 130 Gen-only operators (An operator is the Gen equivalent to a Max/MSP/Jitter object) . Most operators (about 100) perform standard math functions, so you may already have an idea what some of them do. There are, however, about 30 which are unique to Gen in video, and thus worthy of special study. They fall into three broad categories: color, coordinates, and control. So learning jit.gl.pix is not as difficult as it might seem.

My goal in this article is to present a pathway for you to learn jit.gl.pix. I’ll be skimming along, sketching concepts from beginner to advanced, and pointing you to useful but sometimes hard-to-find learning resources. Before we begin, there are two things to note.

Let’s get a feel for the different words that are used to describe roughly the same things. Video is a stream of still images, called frames, consisting of a rectangular arrangement of pixels. Each frame has a width in pixels, and a height in pixels. Typical dimensions are 1920x1080 and 4096x2160. Each pixel has 3 or 4 numbers which specify its color–a mix of red, green, blue, and sometimes alpha (transparency). The color values are typically called channels. Each pixel has color values and location coordinates.

The Jitter matrix can store a single frame of video, but it can do much more. It can contain openGL geometries, audio data, and who knows what else. For our purposes, however, a Jitter matrix is a frame of video; its cells are pixels, and its planes are color channels.

In addition, openGL has its own terminology. 2D images were originally used to create something resembling a texture on the surface of a virtual 3D object, so a 2D image or stream of images is called a texture. Pixels are often called cells of the texture. The list of numbers specifying a color is called a vector, and the individual numbers are called indices (plural of index) or elements of the vector. A single-element vector is called a scalar.

To make talking about all this a little less cumbersome, let’s gloss over some details and assume that each of the rows below consists of approximate synonyms:

Finally, keep in mind that, in OJ (original Jitter) the alpha channel comes first: ARGB. In openGL, and for the rest of this article, alpha is always last: RGBA.

An important thing to remember when working with Max’s openGL objects (a.k.a. OB3D objects) is this: once your images are sent to the graphics processor (the GPU), it’s a big performance loss to bring them back to the CPU. To avoid that, connect the outlets of jit.gl.pix only to other OB3D objects. The final result can be rendered to a jit.window or jit.pwindow object using either jit.world or jit.gl.render, but it’s usually a mistake to connect connect a jit.gl.pix directly to a jit.window, jit.pwindow, or a jit.matrix object.

So beware, Maxer - I break this rule in many of the help files that accompany this tutorial. 

Download the .zip file of example patches found at the bottom of this tutorial, uncompress, and look inside at the patches. They will be used often in this article. Anyway, to get a feel for how costly this technique is, take a look at the jit.gl.pix.norm+snorm+cell.maxhelp patch. Note how bad the frame rate is. Then, delete the connections to those jit.matrix objects and see how the frame rate jumps up. Clearly, there’s a big unnecessary cost - the only time you should use this technique is for debugging (the same way you would use the “print” object) or for learning, which is what we are about to do.

Open the jit.gl.pix.in+out.maxhelp file, and double-click jit.gl.pix to look inside. Whether the input to jit.gl.pix is a Jitter matrix or an openGL texture, the inlet makes sure it’s a texture inside, and that the Gen patch processes each pixel of that texture. Here, it’s a single pixel of a texture that arrives at “in 1” and is sent out “out 1”. The same image arrives at “in 2” where its pixels are multiplied by “param brightness” and sent out “out 2”. The param operator accepts Max messages (param name followed by a float or list) sent to any inlet of jit.gl.pix.

Now look at jit.gl.pix.swiz.maxhelp. The swiz operator, much like Max’s unpack object, splits a list into individual values, a vector into its indices, or a pixel value into its individual colors (all roughly equivalent terminology). The indices of the vector are numbered starting at 0, so “swiz 0” gives us the red value. Conveniently, you can also use “swiz r”. Unlike unpack, if you create a “swiz r g b” operator, it will not have one outlet for each color. Instead, you get a 3-element vector. You can use swiz to rearrange the color channels; “swiz r r r” uses the red value to replace the red, green, and blue values, resulting in a grayscale image. This is similar to typing “$1 $1 $1” into a message box. If you actually want to split the individual colors, you’ll need a separate swiz operator for each color.

Check out jit.gl.pix.vec.maxhelp file. Just as swiz can unpack a vector into scalars, the vec operator can assemble scalars into vectors. (The concat operator, vec’s cousin, can assemble two vectors into a third.) Like pack, vec can also store an initial vector as its arguments. You would have to send a bang message to pack to make it output the default list; in the Gen world that’s neither necessary nor possible. There are no bang messages - or any other Max messages – in Gen. The vector is output each time a pixel is calculated, whether its value changes or not. 

For each pixel that is processed by our jit.gl.pix patch, we can get its location (x,y) with the cell operator, which outputs a two-index vector of horizontal and vertical pixels. However, it’s usually more convenient to use the norm operator. This outputs a vector consisting of the horizontal coordinate, ranging from 0 to 1 (left to right) and the vertical coordinate, ranging from 0 to 1 (top to bottom) regardless of the pixel dimensions of the texture. The jit.gl.pix.norm+snorm+cell.maxhelp patch is your friend here.

Finally, check out the jit.gl.pix.sample+nearest.maxhelp patch. When an inlet is connected to the left inlet of a sample operator, it is able to access the entire texture. The right inlet to sample receives a two-element position vector that is connected to a norm or other operators calculating position coordinates. Then, the sample operator’s output is the pixel vector at that other position. It’s your go-to repositioning tool.

At this point, you have an overview of how these operators work, but your head may be spinning. Fear not. Now it's time to take a leisurely stroll through the eloquent gardens of Gregory Taylor’s The Joy of Swiz and Adventures in Vectorland. (Note that Gen now includes the selector operator.) Check out the jit.gl.pix.mix+selector+?.maxhelp patch to better understand the ? operator. Working through these two articles might take a while, but it’s time spent spent. When done, you will have an understanding of the fine art of psychedelic colors and kaleidoscopic imagery. A career as VJ is not far behind.

You've earned a little fun. Check out this real-time patching video made by Federico Foderaro. Watch from the beginning up to about 4:40. When he starts putting objects inside jit.gl.pix, around 3:30, you should be able to follow along and really understand what he’s doing. That warm glow you feel is pure pixel empowerment.

To get started on the intermediate path, open the Help > Examples > jitter- examples > gen > jit.gl.pix.sprinkle.maxpat. patch and try to figure this patch out on your own. My jit.gl.pix.mix+selector+?.maxhelp patch will explain the mix operator. Using the cell operator enables us to move discrete pixels around with the video noise. The expr operator does vector math much like the Max vexpr object. It has a little mathematical expression as its argument, which takes the input value, multiplies it by 2, then subtracts 1. The param operator not only receives param messages to jit.gl.pix, it can also serve as an argument to the < operator.

The other interesting thing about this patch is that you can’t unlock it and edit it the usual way. When jit.gl.pix has the @gen attribute, it loads a file with that name, in this case “sprinkle.genjit”, which is located in the Max search path (in this case, the same folder as the patch itself). This a great way to save Gen patchers for future use. After building an effect you’d like to use again, open the jit.gl.pix window and select File > Save As... to create your very own genjit. To learn more about how you can use readymade jit.gl.pix abstractions, and how their params appear the attrui object’s menu, select the menu item Help > Reference and search for “Video and Graphics Tutorial 9”.

Now that you’re an intermediate user, you’re going to have to figure things out on your own more and more. Here are some resources to help with that. First of all, the jit.gl.pix documentation page. Surprisingly, this is not that useful for us right now. It’s mostly messages and attributes for the jit.gl.pix object itself; we are more concerned with the Gen patching inside.

On the other hand, the Common Operators page explains all those math functions that you can use throughout the Gen universe. Take a few moments now and look at each one, maybe try out a few that intrigue you. Federico Foderaro puts the math functions to good use in this procedural drawing tutorial Aren’t you glad you didn’t sleep through trigonometry class?

The next really useful reference is the Gen Jitter Operators page. Here you should recognize a few operators we’ve looked at so far. These are unique to video processing. Note that, in jit.gl.pix, “nearest” is the same as “sample”, and “samplepix” and “nearestpix” don’t work at all. Read through the others carefully, and try at least three on your own.

Whoa, way too much work! Let’s play with some patches. Open Help > Examples > jitter- examples > gen > smear.o.vision.maxpat and play with the fourth element (alpha) of erase_color until you get a smearing effect. Note how an empty jit.gl.slab object is used to make a feedback loop around a jit.gl.pix.

Good things come in Packages. Use Package Manager to download and install Andrew Benson’s fabulous Jitter Recipes, then open SceneWarp, one of my all-time favorites. Andrew is the master of video feedback, and you can see how he uses jit.gl.node to render several objects, capture that into a texture, and feed it back into a jit.gl.pix. Both jit.gl.slab and jit.gl.pix make a copy of the incoming textures, which prevents feedback from becoming an infinite loop.

Use the Package Manager again to install 2K’s awesome Vsynth. Launch it and, in the examples tab, click on wfg, and control-click to see a new view of wfg. You can also just type “vs_wfg_s” into an object box and double-click. Take it out of Presentation mode, and you’ll see “jit.gl.pix vsynth @title oscillator” It’s a video oscillator! Now you can channel your inner Bill Etra and become a VJ for a Kraftwerk cover band.

Congratulations, now you’re an intermediate pixel pusher. We’ve covered a lot of material, but there’s one more thing...

Now that you are entering Level 3, it’s time to embrace the semicolon. Open jit.gl.pix.expr+codebox.maxhelp and look inside the “basic” jit.gl.pix object.

Oh no, it’s a box of code!! Didn’t we start this whole thing saying how node-based video effects processing was the way to go? Yes, for passing images and pixels around, it’s perfect, but if you want to do elaborate math, you’ll be happier in the long run if you use some text. Sometimes, all you need is a little algorithm to add functionality that would be difficult to achieve with boxes and patch cords. And there’s no simpler way to code media software than Max’s Gen family. Just look at that single line “out1 = in1 + in2” - it’s even easier than JavaScript.

To get started on solid ground with all this, now is the time to read through several selections of the Gen Overview. Start with “Gen Operators”, and read through “Subpatchers and Abstractions”, stopping before “The gen~ Object”. (Ignore the “history” operator - that makes feedback possible for the audio-only gen~ operator.) This is an excellent tutorial, so make sure you work through all of it. Continue your reading from “Jitter Operators” through to the end of the article. If your brain is a little tired, that’s just what it feels like to be advanced. Be sure to get enough sleep.

Help > Examples > jitter-examples > gen > jit.gl.pix.pinch.maxpat includes a simple codebox demonstrating function definitions, and well as a code version of the sample operator, including an attribute. For a glimpse of just how spectacular code can be, open Help > Examples > jitter-examples > gen > julia.quat.raytracer.maxpat. Even though jit.gl.pix is outputting a 2D image, the code inside makes the image look 3D.

A note about nomenclature: If you’ve already done some work with the vexpr or jit.expr objects, the conventions for inlet names might be a bit confusing. Open the “inlets_and_spaces” tab of jit.gl.pix.expr+codebox.maxhelp patch to see everything all laid out. While you're there, look through each of the other tabs to play with codebox’s functionality and modify it. It’s worth noting that using swizzle notation inside the expr and codebox operators works just like the swiz operator (i.e., “in1.r” instead of “swiz r”). Finally, note that “Param” must be upper-case inside codebox.

For a complete understanding of how the expr and codebox operators work, the GenExpr page is your final homework assignment. Put on your thinking cap, study each section carefully, then make a couple of simple patches with codebox.

And...you’re done. You may notice that it’s taken a couple of weeks to finish this article. (It might be time to do some laundry.) But now you’re an expert in building openGL fragment shaders with Max patches. The world is yours. Power to the pixel!

Learn More: See all the articles in this series

myfavoriteobject-jitglpix.jpg

The jit.gl.pix object has become a go-to object for my visual work. I’d like to present a pathway for you to develop your own skills with the object and with the Gen environment - skimming along, sketching concepts (from beginner to advanced), and pointing you to useful but sometimes hard-to-find learning resources.

Search Results