topher lafata

midiparty is an mxj class which parses midi files and spits them out in either textual or raw format. Right now the demo file is very messy but you will get the idea.It is a work in progress. Good introduction to using Java to interact with midi files.


lafata-midiparty

midiparty

Timothy Place

Last week I arrived home from a 'vacation' in France. In my case though, the term 'vacation' means that I was programming and debugging objects for Max/MSP/Jitter.  The occasion for this trip to France were two workshops focusing on Jamoma that were organized by Pascal Baltazar, GMEA, and Incidents Mémorables.  The workshops were held in Albi and Paris, respectively.

Jamoma is an open-source framework for structured Max patching that allows 'modules' (patches using the framework) to be easily interchanged, exchanged, queried, controlled, and mapped in a high-level manner. Jamoma has been picking up steam over the last couple of years and now has five core developers working on it (Pascal Baltazar, Alexander Refsum Jensenius, Trond Lossius, Dave Watson, and myself) along with feedback, testing, and additional contributions from a number of others.


The location of the first workshop was in Albi, in southern France. Albi was an absolutely gorgeous town. The Tarn river runs through the center of Albi, and it is crossed by several picturesque bridges, one of which is roughly 1000 years old. There is a gigantic and beautiful old cathedral (larger than Notre Dame) and also a museum of art by Toulouse Lautrec. The biggest thing that struck me about southern France, however, is how totally amazing the food and wine were. They were good in Paris too (of course), but in southern France I was knocked off my feet. Words can do no justice to the gastronomic experience.

The Saturday preceding the workshops was occasioned by a series of concerts and installations held in a number of venues throughout Albi by GMEA. In the picture below, the various shoes would stomp, squeek, and drag across the floor. There were three really exceptional pieces on the concerts that caught my attention. One was a video work by Mathieu Chaud from Toulouse; one was a performance by Pascal Baltazar using Max and bunch of goodies plugged into his laptop, and the last one was a performance by Mathieu Chamagne using a Lemur and the pmpd objects for modeling physical object behaviors in Max.

During the week I was able to work with Mathieu on porting the PMPD object to Universal Binaries for the Mac. By the end of the week he had all of them ported and working nicely (they are available on his site). Mathieu also has some stuff on utube that shows a little bit of his Lemur-controlled PMPD patches.  It's just a short excerpt though.

The Jamoma development workshop began on Sunday and ran through Thursday. There were a lot more people involved that I had expected. It was really a group of Max power users. Almost everyone involved in the workshop had developed their own system or framework for structuring Max patches at some point. This led to some good in-depth discussions, feedback, and dialog about how certain problems can (and have been) approached using Max. Most participants gave a presentation on these issues and the frameworks they've developed, and how they may or may not influence or the continued development of Jamoma.

My presentation was a bit more philosophical nature. I focused on the structure of the code underlying Jamoma, and the artistic vision for the code itself (as opposed to the artistic vision for what is done with the code).

In addition to presentations and round-table discussions about various topics, we naturally made some time for hacking and coding. We could probably have done a promo for Apple. Almost every computer was a MacBook or PowerBook. We made tremendous progress in stabilizing and improving the new version of Jamoma. We entered the workshop at version 0.4, and left with a vastly improved version 0.4.1. Since then a 0.4.2 has been released which is working well on Windows in addition to the Mac.

Following the workshop in Albi, we moved North for a one day intensive introductory workshop in Paris. It was held at a gallery called Ars Longa, which provided a nice and cozy space for the event. In addition to Jamoma's core development team, there were about half-a-dozen participants - all of them Max power-users. This meant that we were able to have more good discussions about further refining Jamoma and how it integrates with other systems.

Often times, workshop write-ups seems to end on a generic "and everyone lived happily ever after". I would like to at least avoid the generic part, so I'll back track to the presentations in Albi. Alexander Refsum Jensenius is one of the core developers of Jamoma and gave a presentation of some his gestural research that he's been doing using Max/MSP/Jitter/Jamoma.

It turns out that currently a research hospital in Oslo is using Max and Jamoma for doing analysis of ADHD in rat experiments. They are using some of the modules in Jamoma specifically visualizing the gestural activity in different rats and comparing them. It was quite an interesting presentation!

All in all, I think that both workshops were a great success. I'm very thankful for all of the time energy invested by Pascal, Julia and Thierry at GMEA, Georges Gagneré, and everyone else involved in hosting the workshops to provide such a fruitful experience and an enjoyable experience.

Special thanks to Alexander Refsum Jensenius and Nils Peters for the pictures used in this write up!

Last week I arrived home from a 'vacation' in France. In my case though, the term 'vacation' means that I was programming and debugging objects for Max/MSP/Jitter. The occasion for this trip to France were two workshops focusing on Jamoma that were organized by Pascal Baltazar, GMEA, and Incidents Mémorables. The workshops [described in this article] were held in Albi and Paris, respectively.

jamoma-workshop

Jamoma Workshop

Brad Garton

This is perhaps an unusual article for Cycling '74 to put on their web site, because it has to do with all the languages that Max/MSP isn't.  I have to confess that I'm not really a very good Max-user.  I know only a handful of objects, and I am of the text-based generation that is still a little, um, "graphical-user-interface-challenged".  I basically use Max/MSP only as a window onto computer music languages that I am adept at using.  More and more, though, I am also using Max as base platform for connecting these languages to each other.  One of the really great decisions that the Cycling '74 design team made was to make the development and integration of external objects relatively easy.  This has been a real boost for the classes that I teach at Columbia University, and it has also allowed me much more creative freedom in my compositional work.

I had planned to present a paper/demo at the 2007 Spark Festival in Minneapolis, MN.  However, snow.  Icy precipitation. Two feet of this stuff was on the way.  I rebooked my flight to return to the cozy warmth and safety of New York.  I was bemoaning the fact that I would have to miss the paper session to Andrew Pask and Gregory Taylor at breakfast the day I was now leaving, and Andrew said (you have to imagine an early-morning Kiwi accent): "Hey mate, why don't you write it all up for our web site?"

Before proceeding, download the Max 4.6 patches and information used in this article.

[NOTE:  The following text is written from a Mac OSX perspective, 	but the concepts should be equally applicable for Windows users.  Obviously the externals I discuss will need to be installed 	to run the patches (a list of links is at the end of this article). 	A few of the externals I describe below aren't yet 	available for Windows, but soon!]

A lot of my work involves developing compositional algorithms using script-based languages such as RTcmix or ChucK. I also employ the timbral capabilities imbedded in these languages as well as languages like CSound, JSyn and SuperCollider. In addition to all this, I've come to appreciate the data structuring and control capabilities available through a conceptually-developed language such as JMSL or a higher-level "pure" computer language like Lisp. Finally, I have discovered the joys of connecting the audio flowing from all these snazzy environments together using applications such as Cycling's former product Soundflower/Soundflowerbed. I wondered, what would it be like if I set out to create a patch using all of these languages at once?

I decide to start my computer music language extravaganza with a randomly-shifting cluster of sawtooth waveform notes.  Because I know RTcmix well, I choose the Max/MSP instantiation of the language, [rtcmix~] to create this effect.  (See patch1-rtcmix.pat for this initial sawtooth foray)

(By the way, this patch represents about 96% of my entire Max/MSP knowledge and capabilities...)

In this article, I won't go into the details of how each of these languages work.  There is a lot of on-line documentation for those interested in learning more.  Plus with a little downloading you can hear for yourself how these demo patches function.

And hear them I do!  Sawtooth waves get really annoying after awhile. Just ask my wife and kids. What to do with this annoyance?  Filter it!  There exist many many ways of using digital filters in Max/MSP, but some of the more interesting filters are included in the ChucK language, available in Max/MSP as the [chuck~] external. (See patch2-chuck.pat) I send the sound output of [rtcmix~] through a simple biquad filter in ChucK.  The center frequency of the filter is controlled from the Max/MSP environment.

This external filter control turns out to be a really good thing, because in a silly fit of western compositional conscience I decide that I need to set the filter center frequencies using Real LIve Musical Notation. For this, I can use JMSL.  JSML is a java-based music notation and hierarchical scheduling language that has been ported to work in the [mxj] context. (See patch3-JMSL.pat)

JMSL has many capabilities, and I could have used it -- or any of these languages for that matter -- to control the performance evolution of the patch. Instead I'm using a [metro] object to cycle the JMSL note-sequence repeatedly and drive the [rtcmix~] and [chuck~] objects.  Simplicity is my goal.

As fascinating as these nice, musically-filtered sawtooth sounds are, my personal aesthetic is begging me to add a decent droney bass sound.  CSound to the rescue!  It so happens that I had already built a CSound orchestra to make a droney bass sound.  Including it in the growing patch is almost trivial using the [csound~] object, although a bit of additional work is needed to set the score up properly. (See patch4-csound.pat.  The csdrone.csd csound score/orchestra file is included.)

The icing on the cake for this mash of languages is the inclusion of some high pitched pulse-width-modulation sounds using the SuperCollider (SC3) language.  SC3 is different from the previous languages, in that it runs as a separate application 'outside' Max/MSP.  By employing the  Open Sound Control (OSC) protocol used by SC3 for triggering scripts and events, we can exercise coordinated control from within our Max/MSP patch. (See patch5-SC3.pat.  You will also need sc3-pulseit.rtf SC3 script loaded into SC3, selected and interpreted properly to run the patch.)

The big drawback to the relative 'outside'-ness of the SC3 application is that the audio output is being sent to the computer DACs through a completely separate audio stream.  What if I wanted to pipe the SC3 audio through a happy ChucK filter?  There is a way to do this, but it does require configuration of the  Cycling '74 Soundflower application using the companion Soundflowerbed.app

What I need to do is set up Soundflower/Soundflowerbed to route the audio coming from SC3 into our Max/MSP patch.  There are two ways to do this, and I'm going to describe the "default" way. SC3 normally writes audio to the plain-old two channel output of the computer.  We will use Soundflower/Soundflowerbed to reroute this output into Max/MSP and choose one of the other Soundflower outputs to audition the audio from our ever-growing Max/MSP patch. Here's how:

Start up the Soundflowerbed application.  We are going to select two of the 16 channels to be our "audio monitoring" output.  Just so we can remember easily, let's use the last two (channels 15 and 16) to do this.

From the Soundflowerbed drop-down menu under the Soundflower (16 ch) listing, be sure that channels 1-14 have None checked for their routing:

Set the routing for channels 15 and 16 to Built-in Audio [1] and Built-in Audio [2]:

Next we want to set the default system audio output to go to Soundflower.  Select the Audio Setup... menu item from Soundflowerbed.  This will bring up the "Audio MIDI Setup" Preference.  Set the Default Output to Soundflower (16 ch):

[NOTE:  Be careful -- once you set the "Audio MIDI Setup" default to Soundflower (16 ch), it will affect other applications.  You will probably want to reset this to Built-in Audio when you are finished.]

Now start the patch6-soundflower Max/MSP patch, and use the DSP Status... window (under the Options menu) to set the Driver and the Input Device to Soundflower (16ch):

At this point, audio output from or original patch is disabled, or at least not able to be heard.

To route the audio so that it can be heard, and to route the default output of SC3 into our patch, I need to change the patch so that I can send audio on [dac~] outputs 15 and 16 (the "monitored" outputs) and bring the SC3 audio into the patch from [adc~] inputs 1 and 2 (the default SC3 channels).  This is easy to do by specifying what channels I want in the [dac~] and [adc~] objects. (See patch6-soundflower.pat)   patch6-soundflower.pat

At this point, start up SC3, read the script, fire up the Max/MSP patch, and sound!

There are two points I should make about the SC3 routing.  The first is that SC3 is smart enough to take advantage of all the Soundflower inputs and outputs.  It is not necessary to use the default. The SC3 output ugens can be used to write to any of the Soundflower channels directly.

The second point is slightly more subtle, but it hints at an extraordinary world of possibility.  The output of any audio program can be routed into Max/MSP using Soundflower.  In performance, I have used the marvelous SPEAR analysis/resynthesis program as a performance interface to "scrub" sound analyses and process the resulting sound.  Similarly, the output of the Max/MSP patch itself can be sent elsewhere, perhaps directly to a program like Digital Performer for recording or additional processing. The only drawback is that any program without the ability to address all the Soundflower channels (like SC3) will only be able to write to the default channels 1 and 2.  The combination of several 'external' applications may wind up being mixed inadvertently.

Now SC3 audio is flowing through the patch!  Yay!  I can filter it, I can mangle or munge it, I can mix it willy-nilly with the rest of my sounds.  But instead I'm going to make one final addition to the patch, using a more general computer language.

As happy as I have been with the [metro] controlling the triggers of the different languages in the patch, I would much prefer to use a fractal technique to determine starting points for triggers.  I'm just that kind of guy.  Is it possible to do this by concocting some bizarre dataflow combination of [metro][uzi], [if], or other esoteric set of 'standard' Max/MSP objects?  Perhaps, but it would take someone with a brain radically different than my own to make it happen. Instead, I'm going to turn to the ur-recursive language Lisp to do the work in a few simple lines of code.  The [maxlisp] object lets me do this. (See patch7-maxlisp.pat, the lisp code is in the file fract.lisp)

My work is done!  Five separate computer-music languages, one general-purpose (and also separate) language, all mished together via Max/MSP into one cooperating mass of sound!  And I haven't even hinted at the thrills to be had by employing powerful but more Max/MSP-friendly externals like Peter Castine's Litter package or Peter Elsea's Lobjects. And java!  And javascript!  Yikes!

I'd like to make two final comments.  The first is a plea to developers, and the second is a goad to Max/MSP users.  For developers:  think shared libraries and loadable bundles!  The Soundflower routing for SC3 above works, but I would much prefer to access SC3 functionality directly from within Max/MSP.  Or (for that matter) I wouldn't mind being able to access all of Max/MSP within SC3.  The basic idea is that I like the tight-coupling that can be gained through the imbedding of one application directly inside another.  I've used network approaches in other instances in the past, and although they work well for most situations, the ability to integrate control very closely can lead to much better standalone interfaces and applications. I would love to see the day when bringing in an external application is a simple matter of bundling it properly, finding the right entry-points, and then using the application completely inside an alternative development environment.

The prod to Max/MSP users:  I have to bite my e-mailing tongue on the Max/MSP mailing lists when I read people struggling to work with the creation and accessing of something as simple as indexed arrays of values.  A small investment in learning something like javascript or an even a simpler language like RTcmix or ChucK with rudimentary data-structuring capabilities would solve many of these problems in one or two lines of code. Yes, lines of code.  There are some things that a dataflow approach just isn't all that good at doing (read your Knuth).  Why not take advantage of all the tools available?

And available they are!  Most everything I've used above is downloadable for free or for a very modest sum, and there are many more packages ready for the asking/using.  As an educator intent on teaching a wide range of approaches -- I believe that different languages do in fact structure our creative thinking differently (but that's a whole 'nother article) -- the ability of Max/MSP to "glue" them all together is a real boon.  More importantly, the extended capabilities to which I know have access makes composing and creating music downright enjoyable again. All those sounds!

If you are interested, the original SPARK paper that I did not present because of my snow-fear is here. But you've pretty much read it already.

- Brad Garton
Professor of Music
Director, Columbia University Computer Music Center

Here is an alphabetical listing of many of the objects and languages discussed above:

This is perhaps an unusual article for Cycling '74 to put on their web site, because it has to do with all the languages that Max/MSP isn't. I have to confess that I'm not really a very good Max-user. I know only a handful of objects, and I am of the text-based generation that is still a little, um, "graphical-user-interface-challenged". I basically use Max/MSP only as a window onto computer music languages that I am adept at using. More and more, though, I am also using Max as base platform for connecting these languages to each other. One of the really great decisions that the Cycling '74 design team made was to make the development and integration of external objects relatively easy. This has been a real boost for the classes that I teach at Columbia University, and it has also allowed me much more creative freedom in my compositional work. 

multi-language-maxmsp

Multi-language Max/MSP

Lilli Wessling Hart

Cycling '74

Experimentation and play in the classroom.

Interview created and produced by Sue Costabile for Cycling '74.


Education and Research
Experimentation and play in the classroom.
Interview created and produced by Sue Costabile for Cycling '74.

Cycling74 Perspectives: Matthew Lewis

Matthew Lewis: Education through synesthetic study and play.

a-video-interview-with-matthew-lewis-graphics-research-specialist

A Video Interview with Matthew Lewis, Graphics Research Specialist

pdelges

filesys is a Java class to move, remove or rename a file. It can also create an new folder, remove an empty folder and check the existence of a file.

And thanks to Peter Nyboer from Livid, it is also possible to create a copy of a file.


mxj-filesys-v0-2-3

[mxj filesys], v0.2.5

Example of using Java to control LCD to make an interactive file browsing widget.


lafata-filebrowse

filebrowse

Java classes for the Max mxj extern which enable the execution of OS system commands from within Max.(OS X,PC)


lafata-syscommand

syscommand

rothwell

This is a quick rundown of how the MXJ class loader works, and the implications for class variables (statics).

The first time an MXJ object is instantiated in Max/MSP, a JVM is launched to host the MXJ objects. All MXJ objects are loaded into this JVM by a class loader.

The class loaders is responsible for reading class files from disk and creating Class objects in the JVM, so that actual Java object instances can be created from the classes. Classes are cached: the first time a class is sought, it comes from disk, and on subsequent searches the previously loaded copy is used. Only one Class object will be loaded and used for each class, regardless of how many instances of that class are created. Hence, any class variable (static) will be unique.

MXJ implements automatic reloading of class files: if a class file is modified, then the class will be reloaded. This reloading check is done only when a new MXJ object is created in Max/MSP: it is not a background activity (as in, say, Tomcat).

The reloading is done by discarding the current class loader and building a new one. The existing cache of Class objects is discarded - but the already loaded Class objects, and object instances, are left in place.

The upshot of this behaviour is: when a class file is changed on disk, subsequent MXJ objects will be created with a new class loader (which will cache Class objects), and this class loader will be used for all new MXJ objects up until a new MXJ object has a class file on disk which is newer than the cached Class. At this point a ~~new~~ class loader will be created. And so on.

As a result, class variables behave slightly oddly. Class variables are shared only if they were loaded by the same class loader, and the creation of a new class loader will not impact existing MXJ objects.

Here is an MXJ example to illustrate this behaviour:

package net.loadbang.mxj.demo;

import com.cycling74.max.*;

/** A little test object to show the behaviour of the MXJ
    classloader. */

public class StaticTest extends MaxObject {
    private static int theCounter = 0;

    public StaticTest() {
        theCounter++;

	createInfoOutlet(false);
	declareTypedIO("A","I");		//	bang in, int out
    }

    public void bang() {
        outlet(0, theCounter);
    }
}

Create several MXJ instances over this class, and then bang them: they will all put out the same integer value (which should be the number of MXJ objects created). Each time a new MXJ object is created, every existing one will output the new total.

Now update the class file (by forcing a recompilation) and create some new MXJ objects. These new objects will collectively start counting again from zero. If an existing MJX object is edited, it will join the new group. The old MXJ objects will still share the old total, but no new objects can be added to this group. In effect, there are now two distinct classes called StaticTest, both with instances in Max/MSP, both running, but unable to share data or communicate in the Java heap.

It goes without saying that a new class loader loses the link to ~~all~~ existing classes. Here's a modified version of StaticTest which uses a second class to hold the state:

package net.loadbang.mxj.demo;

import com.cycling74.max.*;

/** A little test object to show the behaviour of the MXJ
    classloader. */

public class StaticTest extends MaxObject {
    private int itsCount;

    public StaticTest() {
        Counter.bump();

	createInfoOutlet(false);
	declareTypedIO("A","I");		//	bang in, int out
    }

    public void bang() {
        outlet(0, Counter.value());
    }
}

When the class file for StaticTest is modified, new MXJ objects start counting afresh. There was no change to the Counter class maintaining the state, but the new class loader brings in a new Class instance for Counter.

(As an aside, updating the class file for Counter has no effect; MXJ is presumably just examining class files for the objects actually instantiated directly by MXJ.)

mxj-class-loading

MXJ Class Loading

sntpMaxClient is a Java class based on the code available on ntp.org.
It returns the date and time of a NTP server.


mxj-sntpmaxclient-v0-1

[mxj sntpMaxClient], v0.1

robertobecerra

So… I want to use Jitter to create objects and distribute them in the visual virtual space, and I need to create matrices with as many locations as objects I want to display.

These objects are to be assigned coordinates and dimensions. Since the objects will be distributed on a circular-like manner, I want to go through each position of the matrix and give it X and Y coordinates.

To address each of the positions of the matrix, (0,0   0,1, 0,2 etc) I decided to create a small routine using Java Script, since I was having problems with the logic in the patcher.

So, the small patch here contains a js object with a Java Script routine in it. This increases its count with every bang it receives, outputing the current values through the first two outlets, and outputing a 1 through the rightmost outlet when the count has reached its maximum.

The format of the counting is binary like, increasing x first until reaching its maximum, then reseting x and increasing y by one, after which x is incremented again until reaching its maximum and so to increas y again by one. This continues until both maximums have been reached.

The dimensions of the count can be modified by sending the message “dim x y” where X and Y are integers.


Search Results