Nathan Wolek

April 12, 2016: An updated version of this tool is now available in the Package Manager.

This package gathers updated versions of projects that were formerly distributed separately as:

It also includes several items that were lurking on my hard drive and never formally released, like the nw.recordplus~ external and some jsui code. My goal is to slowly gather as much of my Max work here as possible, so that it is easier to track changes and share with others. I am also producing short YouTube videos as I go along, so that people can easily see and hear what these items do.

Externals are currently only compiled for the Mac version of Cycling74's Max, but the source code is included as part of the GitHub repository. If you would like to help me compile a binary for Windows, please contact me.


lowkeynw-max-package

LowkeyNW Max package

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.


binary-and-not-binary-counter

Binary, And not Binary, Counter

Andrew Benson

Those of you who are paying close attention already know that Max 5 includes a database that manages all the files in the search path and makes handy things like the File Browser possible. To enable this functionality, we wrote an SQLite object to do all the important work under the hood.  However, the SQLite object in Max isn't really something that you can type into an object box, and it doesn't come with any help files or documentation. In this article, we'll look at ways to interface with this mysterious "no box" object using JavaScript, so that you can build, query, and edit your own databases in Max.

The first thing you might be wondering is, why do I need a database? Well, you can think of a SQL database as a really souped up coll object, with a fairly simple language for doing all sorts of operations on the data.  Also, unlike coll, you never have to explicitly save your changes, and it is a pretty robust and safe solution for managing data. Even if you crash Max, your database will remain unharmed.

The example patches and JavaScript code can be downloaded  here

To get a feel for the essential SQLite interface, open up the the basic-db patch.  In this patch, there is nothing more than a jit.cellblock, a js object, and a bunch of messages. The JavaScript code for this patch provides the most minimal interface possible for sending queries to the SQLite object and formatting the results for display. Let's open up the JavaScript code (easyDatabase.js) to see what's going on.

 var sqlite = new SQLite;
var result = new SQLResult;

function opendb()
{
sqlite.open(x,1); //open a file-based DB
}

To begin, we create our new SQLite and SQLResult objects and assign them to the variables "sqlite" and "result".  The SQLite object has a couple of methods that we'll be using to get a database going.  The first one that you see here is the SQLite.open() method. This opens an existing database, or creates a new one if it doesn't already exist. It expects two arguments - one for the filepath, another to specify if it is file-based or RAM-based. For our purposes, we'll be using a file-based database since it will probably be the most useful for you.

The other method we'll be using extensively is SQLite.exec().  This is the all-purpose query method, and takes as arguments a SQL query string and the name of a SQLResult object to store the results of your query.  Once the query is sent, you can then iterate through the SQLResult to get the resulting values. The SQLite.exec() method is capable of creating,altering, and deleting tables, inserting data, doing all sorts of formatting operations, and performing complex searches depending on the string you supply it. Some examples of common SQL queries are provided in the patch. In our exec() function, you'll also notice the formatResultForCellblock() function being called.  This nice little bit of code simply loops through all the fields in the SQLResult table and outputs them in a way that jit.cellblock will understand.

 function formatResultForCellblock()
{
var numfields = result.numfields();
var numrecords = result.numrecords();

outlet(0, "clear", "all");
outlet(0, "cols", numfields);
outlet(0, "rows", numrecords + 1);    // rows +1 so we can create a header row

for(var i=0; i
outlet(0, "set", i, 0, result.fieldname(i));

for(var i=0; i
for(var j=0; j
outlet(0, "set", j, i+1, result.value(j, i));
}
}

Notice that the result.value() method takes 2 arguments, since you are working with a two-dimensional collection of information. To see our little database in action, try clicking on the different messages in the patch. Each of these messages is an example of common queries that you'll be using. For more extensive documentation on SQL syntax, there is a nice reference and tutorials here. To practice your SQL skills, you can try typing strings into message boxes and send them to the js object to see the result. With a little planning and patching, you can build a pretty useful database using just variations of the provided queries. In next section of this article, we'll be looking at ways to apply this information to a working database-driven patch.

To give an example of a possible application for SQLite within a Max patch, we're going to build an interface that loads a folder of video files into a database and provides controls to add different tags to each clip. In addition, we're also going to create a function to randomly choose a video for playback that has a specified tag. In order to accomplish these things, we'll need to create function-wrappers for the necessary SQL queries, create a couple of patcher interface elements, and make use of the JS Folder object.

We'll go ahead and use the familiar opendb() function from the easyDatabase.js, but we're going to also add a get_all() and menuLoad() function so that we can see some visual feedback and have the patch update when we load a previously saved database.  The get_all() function is just a wrapper for the query exec("SELECT * FROM dumpster");, while the menuLoad() loads a umenu with the elements loaded in the database. The menuLoad() and other functions pass information out of the second outlet, since we are already using the first outlet for our jit.cellblock interface. If we are creating a new database file from scratch, we'll call the build_db() function that creates a TABLE named "dumpster" where we'll store all of our information. More complex databases often use several different cross-referenced tables to manage large amounts of data and relationships between entries, but for our uses all we need is one. Once we create our "dumpster" table, we also create columns to store the filetype of each entry, as well as our two content tags 'color' and 'style'. Now that we have the basic structure in place, we can begin to start populating it with some data.

In order to be of any use to us, we need to grab some meaningful data to load into our database. In this case, we're going to use the names of movie files from a specified folder. In order to accomodate this, we create a function called folderLoad() that makes use of the JS Folder object.  First, we create a new Folder object with the line f = new Folder(xpath);. We can also filter results by specifying a list of filetypes that are supported by Quicktime. We then iterate through our Folder, passing the filename and filetype to the insert_entry() function. This function makes use of JavaScript's user-friendly text-concatenation features to generate a valid SQL string that inserts our information into the table.

 //insert filename and filetype
function insert_entry(){
if(arguments.length==2){
exec("INSERT INTO dumpster ('name','filetype') VALUES ('"+arguments[0]+"','"+arguments[1]+"')");
}
else{
post("Wrong number of arguments");
}
}

Finally, once all the files have been added as new entries in the database, we once again call  get_all() and menuLoad() to update our patcher interface, and then post a message to the Max window to let us know it is all ready to go.

Now that we have a table full of movie names, we can set to work on providing an interface that allows a user to add tags to each movie to describe specific aspects of the clip. In this case, I've elected to use the tab object to provide a consistent range of options for each tag.  Since our JS object has to interface with a variety of objects in this patch, we simply prepend our output messages with a symbol that indicates where the information should go. This way we can use route to pass these messages to the right place.  Using the umenu that is loaded with our movie names, we can call the get_entry function, which will set the tab objects to the proper saved value and allow for changes (using change_entry) to the metadata. Both of these functions simply provide an interface that generates an SQL string to accomplish its task. Using this interface, which could be expanded to provide many other tags with little effort, we can go through our menu of movie files and assign color and style tags to each one.

Now comes the fun part. One of the great features of SQL, and the reason it is so widely used in web applications, is the ability to search the table using different sorts of criteria, and even perform different operations on the results. Our movie selection interface uses a query that searches the table for entries that match the specified metadata tag we click on. We then pass the results of this query to a random number generator to select which entry to display. This selection is then passed on to the umenu object, which tells the jit.qt.movie to read the chosen video.

Now that you have seen some basic techniques for using SQLite in a Max patch, it is up to your imagination how to expand on this and create new and useful solutions. One could easily alter the JavaScript code and patcher interface to load folders full of audio files or images, or even just to store named and tagged presets for a complex patch. Enjoy.

Those of you who are paying close attention already know that Max 5 includes a database that manages all the files in the search path and makes handy things like the File Browser possible. To enable this functionality, we wrote an SQLite object to do all the important work under the hood. However, the SQLite object in Max isn't really something that you can type into an object box, and it doesn't come with any help files or documentation. In this article, we'll look at ways to interface with this mysterious "no box" object using JavaScript, so that you can build, query, and edit your own databases in Max.

data-collection-building-databases-using-sqlite

Data Collection: Building Databases Using SQLite

David Zicarelli

Lilli Wessling Hart

Some of you may have heard that major changes are imminent in the Max world, and there is a lot of speculation about what those changes might be. On the eve of our first public exposition of the new version of Max at the AES convention in New York, I thought it would be appropriate to offer some details on the product.

Max 5 will be released in the first quarter of 2008, and will include (and require) new versions of MSP and Jitter. While MSP and Jitter will have some enhancements, the real story is the environment itself.


Many software companies seem willing to claim that every problem you could possibly have will magically be solved by upgrading to their latest version. But often as not, upgrades mean changes in the way you're used to working and new compatibility problems. I wish I could say that you'll be able to start using our amazing new version and everything will sparkle (including your clothes). But I'd rather be honest and say that the reality of software development is that in order to get shiny and sparkling, you have to be willing to make big changes. Max 5 represents one of those times. In almost twenty years of working on this software, there's never been anything close to the transformation we're undertaking.

For current users, I would describe Max 5 as analogous to Apple's transition from Mac OS 9 and Mac OS X. At some point, Apple decided that the technological foundation of their operating system was unsustainable, and required a completely new approach. We came to the same conclusion about many aspects of Max, and especially about the graphical interface -- often the most complicated and difficult system within any large application software project.

Max was based on the way the Macintosh worked in 1987. Since then, a lot of things have changed about graphical interfaces, file systems, and pretty much everything else. As a result, the assumptions of 1987 were simply too deeply embedded to keep Max going for another 20 years with the same internal codebase. This became increasingly apparent in recent years, as we seemed be doing nothing but patching Max to keep it working with the latest hardware and software.

If you write computer programs, you have two jobs: you can make the programs do new things by adding features, or you can fix your programs to be compatible with something. Adding features is fun. Maintaining compatibility is entirely necessary, but for me it's not very fun. And I don't think many other people find it fun either.

I've wanted to make Max better, but recently most of my work has been the drudgery of making it operate on OS X, or on Windows, or on Intel processors. While I've been doing this, I've also been accumulating ideas for what I would do once I got over all this kind of work.

Well, that day did come when we finally finished the Intel port of the OS X version, although it took about a year longer than I thought it would. Once I was able to clear that off my desk, I began organizing my thoughts about what Max requires to survive another 20 years.

There are two aspects to this. First there is the boring part - if Max is going to survive another 20 years it needs to be rewritten to work easily on multiple operating systems, on diverse hardware, and in various places of the world. Second (and less boring) is that Max has to change to fit the way people use computers in 2007, rather than the way they used them in 1987.

One of my dreams is to avoid wasting an entire year's effort the next time a hardware or software transition is forced on us. We were going to build Max on top of a platform-independent framework that will isolate us from the day-to-day nonsense Apple and Microsoft keep throwing at us. And, ultimately, we want to port Max to Linux. (No, we haven't done this yet, but we can now conceive of doing it.)

Getting rid of our "legacy of dependence" stretching back to the Mac OS circa 1987 takes some time, which is why you haven't seen a new version of Max in a while. But you will soon, so let's talk about the second part of the project -- rethinking how people work with Max.

Max 5 doesn't add hundreds of new objects. There are a dozen or so, but Max has enough objects already. It does not go crazy with social networking features, or run your cell phone, or introduce an exotic new computer science paradigm of object-oriented goodness. I'm not saying those aren't worthy things to do, but that's not what Max 5 is about. In other words, you still use the same basic collection of objects in the same way.

Max 5 is based on being easier to use, easier to learn, and easier to deal with. In order to work toward those goals, we've put a lot of effort into creating a more modern graphical user interface for interactive real-time graphical programmers. I should point out that a programming environment is not the first thing that people have in mind when they think about graphical user interfaces.

I can't provide an exhaustive list, but let me highlight a few of the ways we addressed each of the three areas discussed above.

Objects interact with time in ways that are more meaningful than milliseconds.

The patcher is variable resolution and can be zoomed in and out.

A simplified and more consistent interface, identical on Mac and Windows.

A new object palette (with nice big resizable icons!) works as a visual catalog.

The documentation is completely integrated into the user interface.

A searchable database of objects, media, examples, and documentation integrates all of the provided material.

Introductory tutorials have been completely rewritten, and include integrated patches.

New interactive debugging tools make figuring out what your patch is doing (almost) fun.

Third-party object developers can now use all of our documentation tools for their products.

The interface can easily be localized and customized.

A new file format is more readable, extensible and reliable.

A new interface layer -- "Presentation Mode" – provides a new way to build user interfaces without cluttering your patch.

The installation and authorization experience is vastly improved.

Behind these ease-of-use goals you will find a lot of new software technology that we've been working on for over two years. I won't bore you with the details, but pretty much every piece of Max (except the part that runs your patch) has been modernized. We've dropped the MDI interface on Windows in favor of a more elegant SDI model. The graphics are composited (which means things can be translucent), and the programs are remarkably identical between platforms. And because we needed it for our documentation, we'll let you drop a web browser into your patcher whenever you need one.

A few years ago we conducted a survey of Max users, and the results completely changed the way I thought about the software. What became clear was that Max users do not think of themselves as working with sound, or images, or controllers. Instead, they see themselves as working with ideas. Max, therefore, is more of a concept editor than a media editor.

Because Max users are concerned with cognitive problems, I realized that in order to be effective software, Max could not itself be a cognitive problem. There are many challenges in trying to think while using a computer, but to me, there was a simple and fundamental aspect of using Max we could immediately improve: remembering how things work.

Perhaps you have memorized how everything in Max works. I have not – I am constantly consulting the help files and documentation, and I feel that every moment I spend looking for the PDF or deciphering a help patch takes my concentration away from the problem at hand. We tried to look at every "moment" in the life of the Max programmer, and want to make the information that applied to that situation immediately available.

Let me give you just one example of what I'm talking about. In Max 4.x there was something we call the "quick reference" menu. You might not even know about it because it involves clicking on an object with two keys held down (and naturally, I can't remember which ones they are right now!). We've improved this feature in a number of ways. First, to see the menu, all you have to do is click on the inlet of the object. A menu of all the messages and attributes for the object will pop up. And when you mouse over a message name, a description of what it does appears taken directly from the Max reference documentation. Select the message, and Max creates a message box containing the message name already connected to the object's inlet.

The point is, even if you're really into Max, we think this stuff is going to make a difference for you. And if you could never really "get" Max, we think it's likely that the new version will lead you closer to mastery.

Of course, no decent software upgrade is complete without a ton of little improvements, and Max 5 has more than its share. If you are really into the software, we hope you'll appreciate the many little things we've done to make Max a little less annoying. Here are a few, just picked at random.

The new patcher file format is designed to let you to save files for the preset object without fear that your preset won't work if you change the patch.

You no longer need to prepend a message with "symbol" in order to send it to a message box.

You can double-click on a search path listed in the file preferences window and it will show you where the path is on your hard drive.

You can edit the data in the pattrstorage window.

Any movie, audio file, or image can be previewed directly inside the new File Browser, and then dragged onto the object where you want to use it.

poly~ distributes its subpatchers onto multiple processors, resulting in a substantial performance improvement in many cases

As with any transition, not everything is "the same only better." I've told everyone who would listen that the timeline object was a dead end, and it is now history. I think the new musical time system, which I'll discuss in a future article, offers far more power and flexibility than the timeline, but it is not identical. And we are by no means finished with timeline-like things for the future -- but even to compare them to timeline offends me. We've also dropped the editing window in the detonate object and we're also not moving the env and envi objects to Max 5. I doubt many people will miss these things.

Finally let's talk about compatibility, the dirty underbelly of any big software project.

At the present time, we're starting to work on ensuring that the vast majority of existing Max 4.x patches will work in Max 5 without any appreciable pain and suffering. After all, that wouldn't really do much for ease-of-use would it?

However, a few things are just not going to be possible to transfer to Max 5 unchanged. The main issue is external object compatibility. While most objects are going to work without any modification in Max 5, third-party user interface objects such as sliders and dials, and objects that display something in their own window will not work and will need to be rewritten completely. There really aren't very many of these objects, and developing new ones is now so much easier, we expect the trade-off will be worth it in the long run. We really needed to ditch the old UI object model to be able to do any of the cool new things we're doing.

Another thing that won't work is Pluggo plug-ins based on Max 4. These will need to be converted to a new format based on Max 5. Unfortunately, this new format is unlikely to be ready when Max 5 is first released. If your life revolves around plug-in development, you'll probably want to wait to upgrade until we change our plug-in support to work with the new core environment. Support for non-Pluggo VST plug-ins has improved in Max 5.

Anything written in Javascript to work in jsui or Java to work with mxj will work fine in Max 5. There's a new drawing model in Max 5 available from within Javascript that provides a number of improvements over the existing Sketch model, but Sketch is completely supported.

As I mentioned above, Max 5 has a new file format. It is entirely textual -- it's based on JSON which is a more readable version of XML -- and if you need to, you'll be able to look at a file and immediately see what everything means. It provides for Unicode character support, unlike the old format, which only allowed you to save comments in unicode if you checked a special box. Max 5 can also read and write files with long filenames (finally!) on both the Mac and Windows. However, we are not planning to export Max 4.x files from Max 5. Someone could probably write a converter fairly easily, but it probably won't be us.

Over the next few months I'll be writing regular articles explaining more details about Max 5. I'll also keep you up to date on our progress as we move closer to a release. At this point, we are not planning any sort of public beta testing period, primarily because our documentation is still in the process of being revised and integrated. We also want to spend our time making the software better and more reliable, not answering questions about how it works. However, we're considering some alternative strategies for ensuring we've made Max 5 as compatible and reliable as possible when it is released.

Max 5 is a new beginning. It is really a wonderful testament to the growth of the Max community over the past twenty years that you've given us the opportunity to invest so much time and energy into this new version. I very much hope you will think our efforts will makes your creative life a little happier.

Some of you may have heard that major changes are imminent in the Max world, and there is a lot of speculation about what those changes might be. On the eve of our first public exposition of the new version of Max at the AES convention in New York, I thought it would be appropriate to offer some details on the product. 

max-5-what-it-is-and-isnt

Max 5: What It Is (and Isn't)

arne

One of the beauties of Max is its simplicity: the ability to quickly create a patch that does something artistically interesting. Part of this has to do with its visual programming style - patchcords allow us to see the relationship between graphic objects. However, unless you limit yourself to creating only straightforward patches, your patch can become a spaghetti-like series of connections that confound attempts at debugging.

Please note: This article was written for Max 4.6 originally.

Some users suggest that the potential of Max resides in its simplicity; in order to create truly complex patches, one must use procedural languages that Max can contain within it: Java, Javascript, ChuCK, RTCmix, et al. But I've been using Max for a long time, and I really feel comfortable working within its environment: I don't want to learn another language. Can't I use Max to create Really Complex Patches?

Of course, complexity can mean many different things. I've stared at single window FFT patchers for an hour, trying to understand them. But that type of patch will behave the same way (hopefully) every time. The complexity that I'm talking about are those patches that take ages to load, the ones with seemingly countless nested subpatchers that you can't even remember creating.

In the past few years, I've spent most of my Max time developing one major patch, and I've had to develop some procedures that deal with organizing complexity within Max itself.

A caveat: I am not trained as a programmer - I'm a composer who programs. The ideas that I'm suggesting are ones that I've found - in my sixteen years of programming specifically in Max - work well.

Some of these ideas are probably found in a first year programming course - but if you've taken a first year programming course, you probably don't need to read this, right?

And you've read the tutorials, right? For example, page 338, "Encapsulation", which deals with some issues of complex patches, and page 386 "Debugging", which deals with some basic debugging ideas.

The tendency to take working patches and keep adding to them is one way to create complexity, perhaps inadvertently. Unfortunately, this can also lead to confusion, particularly if one simply adds more patch cords between processes.

For example, a given gate may control whether a process operates. As new situations arise, new processes are added via more patchcords to control this gate; while each addition may make perfect sense while you are adding it, a week later it may have become difficult to determine the relationship between processes that control the gate.

There are ways to solve this (outlined later), but it involves time spent cleaning up code; I don't think any programmers enjoy cleaning up code; most would rather solve a new problem. Therefore, it's best to avoid these problems before they happen.

In these cases, it's sometimes better to start over, salvaging parts of the existing code as modules. Instead of adding more rooms to your clubhouse, lay a better foundation and build your mansion from scratch.

One very useful traditional idea is the concept of structured programming. This notion suggests that "large problems are more easily solved if treated as collections of smaller problems" (O. J. Dahl, E. W. Dijkstra, and C. A. R. Hoare, Structured Programming, London, Academic Press, 1972). These "small problems" are handled in individual modules - in our case, they would be subpatchers or abstractions.

We tend to think of subpatchers as a method to clean up code (you gotta love the En-capsulate command!); however, designing your patch modularly - with subpatchers acting as modules - has many benefits. As outlined in in the Tutorials (p.339), these include:

modules can be reused. Once you have one that works, you don't have to keep re-writing it;

it is easier to see how a program works later on, especially if you need to debug it.

If you find that you are using the same subpatcher over and over, then it is time to make that subpatcher an abstraction by saving it separately. When using abstractions, you are guaranteed of reusing working code; this becomes important when you edit the original abstraction - you know that all instances will be updated (rather than having to hunt around looking for copies of nested subpatchers).

On the other hand, handling data inside an abstraction is sometimes tricky during debugging. Naming data structures using changeable arguments (for example, giving a coll the name #1_mycoll or a value object the name #1_myvalue) will clear them in all instances when you resave the original patcher. The use of an initialization routine will be discussed later.

Functional strength - defining a subpatcher

One tenet of structured programming has to do with how information flows between modules. Each module should be self contained, and have (ideally) one entry and one exit point; you shouldn't jump from the middle of one module to the middle of another. In Max, this means that each subpatcher should have a limited number of inlets and outlets.

Furthermore, each subpatcher should execute a clear task (and be named after that task): if your subpatcher does this, it would be considered to have functional strength (which is a good thing).

Does it take more than a few words to describe the purpose of a subpatcher? Does the name contain any conjunctions? If yes, the module is not "functionally bound", and needs to be broken up.

The function involves two separate concepts (checking the data, then sending it out). The following is not only cleaner and easier to debug, it also guarantees that data is not sent out until after it is checked.

Following these few concepts, patches with much clearer program flow will result:

An example of structured programming within Max

Notice that each patcher has one inlet (entry point) and, at most, two outlets (exit points). This ensures that the process will be compete before moving to the next patcher.

Using a trigger object, which works very well when executing straightforward processes (storing data, for example), can potentially cause problems.

Questionable program flow that may lead to stack overflow 

In this case, let's assume [process_data] involves some complex, time consuming cal-culations. In order to avoid stack overflow, you might put one or more deferlow objects inside this subpatcher. In that case, when does [clear_flags] get executed? Before or after deferred control returns to [process_data]?

I prefer to avoid these types of questions, and instead guarantee the program flow in the earlier version.

It is also much easier to trace program flow in modular code. Even after each subpatcher has been tested, it is necessary to follow how the program passes control amongst its modules. I use the led object to help me see this during debugging:

Using the led object to trace program flow

The output of each subpatcher is actually connected to a subpatcher, which is connected to the led:

This assumes that each subpatcher is passing bangs, which is something I always try to do. In this way, another tenet from structured programming is followed: don't pass data between modules. Instead, store the data; each subpatcher can affect data, but then pass control to the next subpatcher.

Here are a few ideas that I've found that I use a lot to help me organize large patches. These aren't just for large patches, but habits that I have found to be useful in all my Max projects:

loadbang works great in basic patches, but can start getting problematic when used to initialize larger patches that involve calculations to initialize data, or cases when one process must be initialized before another.

Similar to the methods of structured programming, I guarantee the order in which initialization occurs:

Initially a great way to get rid of extraneous patch cords, these objects can lead to other problems.

In the following patch, a message is sent to the named receive object "new_result". The potential problem is at the receiving end. If there are several receive objects with this name, which one will get the message first?

A typical, if somewhat hazardous, use of send/receive

In this example, the lower receive will get the message first (since Max works not only right to left, but also bottom to top in ordering messages). But what if the receive objects are contained within several layers of subpatchers?

This is further complicated if the subpatchers [do_something] and [do_something_else] operate upon the same data - the order of their operation may be important.

If [calculate_something] only operates upon data, and the result of the calculation is not time dependent (for example, the next note in a pre-composed melody that will be played later), the output should be stored for later use. The best object for this is value.

Then, inside the other patchers [do_something] and [do_something_else], this data can be accessed when it is needed:

As already mentioned, process order can be controlled so that data is stored before it is operated upon. For example, the following is one way to do so (although the storing of data in the value [new_result] could have been done inside [calculate_something]:

Value objects are great for storing data for later use, but they don't tell you when the data has changed. For example, incoming sensor data may be stored in one or more value objects, but the patcher to initiate action based upon this new data isn't directly notified.

Therefore, a send/receive pair is still necessary. Use such pairs when you are dealing with time-based data.

Storing incoming data, and notifying that new data has come in

And in the patcher that operates upon the data:

Accessing incoming data immediately after it has come in

Because larger patches often need to store lots of data, coll can initially be your friend. One of the best features of coll is the ability to quickly and easily see your data. Unfortunately, I have had some less than stellar experiences with coll when dealing with large sets of data required in a timely manner (in these cases, I have moved to Java to utilize the many data handling routines available within it).

However, I find coll to be sufficient when working with smaller sets of data. One of its quirks is that it can stop program flow if you request data that isn't there, since it won't return anything (unlike table, for example, which will always return something). See the left side of the example below.

In these cases, use a flag to test whether data is in coll: see the right side of the example below.

Using flags to know when data isn't available in coll

Create abstractions to handle data between instances

One very powerful feature of Max is the ability to use instances: abstractions that use arguments to maintain individual data within them (for example, #1_mycoll within the original abstraction.

I use a single abstraction to handle all storage of coll data, and another to handle all value data. In these cases, a single coll or value will hold the data for all instances, making it much easier to handle data, especially during debugging and testing.

The usage of store_coll in an abstraction is shown below. In this case, the coll [play-pattern] will hold the patterns for all beats of an instance; this particular subpatcher will move the current pattern into [playpattern] at the current beat offset:

Use the text object to track program flow

The earlier method of tracking program flow using led objects works fine for debugging a single subpatcher, but when everything is put together and several instances of an large abstraction are working, this is ineffective. I often want to know what the data in a value or coll is when entering and exiting a given subpatcher. Printing it to the Max window is equally ineffective, since all instances would print (and cause an overflow of information).

In these cases, I use the text object to collect this information, one for each instance. In the example below, I want to know what [next_pattern] is at a certain point of the patch. The value is unpacked (unpack is initialized with negative numbers in case [next_pattern] was not initialized, which I would then notice), and combined into a longer message using sprintf, and finally sent to a receive object named [collect]:

One of the beauties of Max is its simplicity: the ability to quickly create a patch that does something artistically interesting. Part of this has to do with its visual programming style - patchcords allow us to see the relationship between graphic objects. However, unless you limit yourself to creating only straightforward patches, your patch can become a spaghetti-like series of connections that confound attempts at debugging.

Please note: This article was written for Max 4.6 originally

managing-complex-patches-in-max

Managing Complex Patches in Max

Timothy Place

It doesn't have quite the same ring as Letterman's "Stupid Pet Tricks" but you get the point... This hopefully periodic new column will attempt to get Max's JavaScript object, JS, to jump through a few hoops and garner our applause. The idea is similar to Andrew Benson's excellent Jitter Recipe's. So let's get started...

Stupid JS Trick #1: Resizing Your Abstraction's Patcher Interface

The method discussed here for resizing patcher windows and bpatcher boxes is used in the Jamoma project.  This screenshot shows the same patcher (Jamoma's limiter~ module) loaded as a plain object and in a bpatcher.

Here's the challenge: we want to create an abstraction (a Max patch that is loaded as an object in another patch). When the user double-clicks our object, it should open an interface window. Rather than having to remember to manually resize the window tediously every time we save the abstraction, we want to have it happen automatically. And just to make things more interesting, let's say that we want to have this little JS gizmo inside of another abstraction inside of the abstraction.

var my_width = 200;  // number of pixels wide and/or high...
var my_height = 350; // dimensions include scroll bars if present...

function loadbang()
{
	// get the patch's window:
	var grandparent_window = this.patcher.parentpatcher.wind;
	// get the patch's object box:
	var grandparent_patch = grandparent_window.assoc;
	if(grandparent_patch.box){
		grandparent_window.size = [my_width, my_height];
		// remove the scroll bars:
		grandparent_window.hasgrow = 0;
	}
}

After mulling this over briefly (all of the functions are documented in the "Javascript in Max" PDF that is in the Max documentation), we can make a couple of improvements. Namely, what happens if a user loads our abstraction in a bpatcher? Ideally, we want the bpatcher to be automatically sized too. How do we do that?

The code below is an amended version of what we did above. We test to see if we are in a bpatcher using a questionable method where we see how high the object box is, and assume it is not a normal object if the height is more than 50 pixels. Unless you use a really big font in your Max objects, or your bpatcher is really short, then this should work.

This hopefully periodic new column will attempt to get Max's JavaScript object, JS, to jump through a few hoops and garner our applause.

stupid-js-tricks

Stupid JS Tricks

aconica

There`s one audio computer with Ableton Live + Max for Live, communicating with another machine which is responisble for LEDs, touchscreen and general room lighting. 

mendelssohn-museum-effektorium

Mendelssohn Museum Effektorium

IanniX

IanniX is a graphical standalone open-source sequencer, based on Iannis Xenakis works, for digital art. IanniX syncs via Open Sound Control (OSC) events and curves to your real-time environment, for example MaxMSP/Jitter.

— It can be used with a diversity of software and hardware tools,

— It can be modified and operated in real-time,

— IanniX's graphical space spans several dimensions and time scales,

— The OSC protocol allows fast network communication,

— It is licensed under GPL 3, free and cross-platform,

— Scripts for IanniX can be written using JavaScript to create complex and generative scores.


iannix-1

Leo van der Veen

Record a stream of int/float/lists or even symbols to output them later in a specified amount of time.


Search Results