Week 6 - Class 1

In this class, we will be using the files found in the 'second' monome patch fixtures, found by clicking on this link.

This week, we will be diving into ways of storing, displaying and accessing monome settings. One of the most important things that we have to do is to be able to 'toggle' values. This requires us to store the state of the monome in our patch so that we can access it. One way is to store and retrieve data from a jit.matrix (this is the method preferred by some of the Cycling '74 people):

Note how this method uses the 'name' of a matrix to share the data from different locations in a patch.

Another way to do store and access monome data, preferred by many of the people at monome, is to use a matrixctrl object, which presents a user interface for a grid-like surface. This is the approach I tend to use as well. Here's an example of that:

If we want to work with multiple LED levels, we can change the matrixctrl to use multiple internal values, then increment them as necessary. The third patch shows this in action (you'll have to check in the inspector to see where the internal settings have been changed:

Finally, we will want to learn to combine the storage and display capabilities of the monome with a 'sequencing' type of application - one where we step through the columns, get the current data, and use it to perform some sort of function. This can get pretty complex, but the result is worth it. The fourth patch is a fully-realized sequencer, with the data available as a list:

So, what do we do with this? You could conceivably use this data to create MIDI notes, change audio volume levels or adjust video color settings. In my case, I used it to drive a simple tuned percussion patch:

The details of everything you need to know (from a specification standpoint) is available here: the monome tech docs

In-class Activities:



ADDENDUM: Javascript Management of the Monome

This addendum will be using the files found in the 'third' monome patch fixture set, found by clicking on this link.

While I'm a big fan of visual programming, sometimes it isn't as efficient as using textual programming. Today, we are going to look at using the "js" object - an embedded Javascript implementation - to work with our monome devices.

The js object is created with the name of a Javascript file that will be used for the internal logic of the object. There are a variety of commands specific to how Javascript works within Max; in this case, we are going to look at a simple - and rather pedantic - example found in the fixtures.

At the top of the program are some parts that are used to describe how the object looks to the outside world (Does it automatically update when changed? How many inlets and outlets does it have?). Beyond that, we set up some variables - in this case, a virtualization of a 16x8 monome grid, and a flag telling us whether we are going to toggle values or just display them as-is.

After that, we have Javascript functions that match the names of the messages it is to receive, along with the parameter lists that they will have. For example, in the 'key' object, we state that a column, row and status value will all be received.

In this Javascript example, I've also created a simple function that I use to send out the row, column and value of any cell that is selected. I do this so that, as I expand the programming, I don't have to reiterate this part of the programming. This is typical reuse of function content.

You can find out a lot more about Javascript in Max by looking at that part of the documentation - either in the built-in docs, or using the online documentation.


Week 6 - Class 2

In this class, we will be using the files found in the 'fourth' monome patch fixture set, found by clicking on this link.

One of the things I often talk about when helping people work on their projects is to find 'higher order' ways of influencing a process. For example, rather than turning on a light when you clap your hands, maybe you are looking for the higher pitch of a child's handclap, or a handclap only when another has not been heard in five minutes. Do something that isn't a direct "push a button, get a result" sort of function.

One of the ways you can do this is to have external systems 'inform' your user interface, and you react to changes in that interface. A perfect example is to capture the video stream of a webcam, display it on your monome, then allow the user to select a location on the image to report upon. Here's an example of that:

This system has to do a few things:

You can see that the way you would interact with the monome is much different if the user interface represents the constantly changing webcam feed rather than tracking a static user interface. In this case, we get a number that represents the value of a pixel; this could easily be used for audio volume, visual effect or MIDI message output.

NOTE: There is no class on Monday! Projects will be due on Wednesday!


Return to the class index.
Last update: 04/26/2016