Mike Ross

Newbie here coming from Quartz Composer. I am trying to re-create a patch I had in Quartz Composer, and having difficulty figuring out the relevant MAX/Jitter approach. I would be grateful if anyone could help point me in the right direction.

The idea is to divide the screen space into a grid, and assign each sub-section of the grid to a midi note. So for a 5x5 grid, I would assign it to a 25-note range of midi-keys on a keyboard controller. Pressing a key would cause a video to play at the associated grid position, with effects such as frequency-shifting and color-tinting determined by how the key was pressed. So I am thinking that I would want to create a subpatch that determines how the video is played within a grid position, then create 25 instances of the subpatch for each midi-key.

The key thing is that I would like the grid size to be determined dynamically. So, I could change it to, for example, a 6x10 grid, with a 60-note MIDI range.

I am looking for any guidelines on what sort of nodes I should research to accomplish this. In Quartz Composer, this is easily done with a multiplexer, where each instance has access to its index, and thus knows its grid position. This is also similar to the concept of Copy-Stamping in Houdini (another node-based framework I use). But I'm not sure what principles to use in MAX. It feels like I might be able to use the poly~ node to create N videos, then combine them with jit.glue. But I'm not sure if poly~ can handle dynamically changing the grid size. From what I have seen, you have to pre-define the number of inputs and outputs and manually wire them up.

As a newbie, its a bit hard to figure out what to even search for. I would be grateful for any pointers, or suggestions for relevant tutorials, examples, or node references.

The key thing is that I would like the grid size to be determined dynamically. So, I could change it to, for example, a 6x10 grid, with a 60-note MIDI range.  

I am looking for any guidelines on what sort of nodes I should research to accomplish this. In Quartz Composer, this is easily done with a multiplexer, where each instance has access to its index, and thus knows its grid position.  This is also similar to the concept of Copy-Stamping in Houdini (another node-based framework I use). But I'm not sure what principles to use in MAX. It feels like I might be able to use the poly~ node to create N videos, then combine them with jit.glue. But I'm not sure if poly~ can handle dynamically changing the grid size. From what I have seen, you have to pre-define the number of inputs and outputs and manually wire them up.

As a newbie, its a bit hard to figure out what to even search for. I would be grateful for any pointers, or suggestions for relevant tutorials, examples, or node references. 

dynamically-allocating-number-of-video-instances

for the midi processing/video segment processing look at the poly object-- i think you can dynamically allocate number of voices (if not just allocate a maximum possible number); for the rendering individual matrices into a grid there's jit.glue, but it wont reconfigure dynamically

sorry, i didn't read your entire post, so my previous answer is idiotic.

try using the dim message to dynamically change the dimensions of the output matrix ie (dim 10 6)

here's an example patch, which can coerce a single-row matrix into one of arbitrary x, y dimensions:

sorry, i didn't read your entire post, so my previous answer is idiotic.
try using the dim message to dynamically change the dimensions of the output matrix ie (dim 10 6)
here's an example patch, which can coerce a single-row matrix into one of arbitrary x, y dimensions:


One approach I've used is to put a jit.movie, jit.gl.texture, and jit.gl.videoplane into a poly~

The position message to the various videoplanes gives you nice flexibility for spacing, changing arrangement of videos with a motion effect, &c...

You want to default your videoplanes to @enable 0 so that inactive instances don't appear as black rectangles in your jit.window, but note that since 'enable' is a reserved word for poly~, you need to define another message to enable/disable from outside the poly~.

I'll try to dig up and example that is not too byzantine tomorrow.

Here is an example adapted from a denser project -- I tired to thin out inessentials to show the fundamental concept, and popped out all the UI with panels; let me know if this approaches what you are after, and if you have any questions. Some of the grid math is perhaps easier done in Javascript or Lua, but it's all done in Max here.

Poly Patcher (save the Poly Patcher as jitter_GL_poly.maxpat ):

Both of these patches are really helpful. I think this gives me enough to solve my problem. JJ's patch is almost exactly what I want to do. But I'm also studying FP's patch because it seems to fold some of the row/col math into the fill/spill objects (though perhaps making it more difficult to adjust spacing?). Thank you both! What an amazing community. --Mike

To both Floating Point and John Jannone:
Both of these patches are really helpful. I think this gives me enough to solve my problem. JJ's patch is almost exactly what I want to do. But I'm also studying FP's patch because it seems to fold some of the row/col math into the fill/spill objects (though perhaps making it more difficult to adjust spacing?). Thank you both! What an amazing community. --Mike


Hello. Here is my approach, based on the poly~ object and jit.gl.cornerpin, which gives you pixel accuracy in the positioning of the planes. They are positioned and scaled according to their instance number, the window resolution and the grid size, and the system automatically adjusts if any of these values changes.

I've added a MIDI keyboard simulation (note, velocity). The note defines which instance to send the information, and the velocity starts and stops the respective video playback. It is polyphonic.

With this approach, performance should be nice.

I hope it helps! Oh, and welcome to the Max community!

Hello. Here is my approach, based on the poly~ object and jit.gl.cornerpin, which gives you pixel accuracy in the positioning of the planes. They are positioned and scaled according to their instance number, the window resolution and the grid size, and the system automatically adjusts if any of these values changes.
I've added a MIDI keyboard simulation (note, velocity). The note defines which instance to send the information, and the velocity starts and stops the respective video playback. It is polyphonic.
With this approach, performance should be nice.
I hope it helps! Oh, and welcome to the Max community!

I ran across another solution that does not use poly~ or openGL. What I'm sending is adapted from a project developed by my brilliant student Isaac Eddy a few years ago, with some efficiency improvements from me. It is based on the idea that you'll want a small, fixed number of movies, and a variable grid (Isaac's original patch in fact just used a single movie with the in- and out-points changed from player to player!). If you want a large number of movies, you will want to replace the MultiPlayer patchers with poly~ (Also: in the original patch the four MultiPlayer patchers are in fact abstractions with # arguments for the coll names. I rebuilt them as simple patchers just to simplify the patch a bit for study...).

Dynamically allocating number of video instances