A Comparison of jMax and PD: Architecture and Design

This paper examines the differences between jMax and PD in terms of their core functionality and implementation details at a source-code level while providing a high-level examination of the overall ramifications.

One striking difference between these two programs is in overall design; jMax is modular while PD is integrated. Modularity is perhaps the most prominent feature of jMax as can be seen in the client/server model, the separation of the Max objects into individually loadable packages, and in the use of modules to provide the majority of the server functionality. For example, the FTS server uses modules to provide scheduling, message passing, file handling, signal processing, a configuration system, client communications, and audio input and output. This modularity gives jMax a great deal of flexibility and allows it to be used with other clients, but adds many layers of complexity to the program. Contrastingly, PD is a tightly integrated program that, though object-oriented, provides no built-in method for the replacement of large sections at compile time. This allows PD to be a much simpler and smaller while providing comparable features; PD has only approximately 25,000 lines of source code compared to 150,000 for jMax.

Both programs have extended the Max programming language to address common issues. jMax introduces named variables and expressions. These variables, which are static at runtime, have the main advantage of limited scope. They are visible within a patch and its subpatches, but not parent patches. Variables or variables used in expressions can be used in the instantiation of objects, adding considerable flexibility. PD removes integer types and uses only floating-point types for messages, simplifying the internal structure and dramatically reducing the overall size of the program.

The most important aspect of both of these programs, and an area of significant difference, is the way in which they execute the signal-processing graph. jMax uses a virtual machine, called FTL, to execute a compiled DSP graph consisting of both signal-processing functions and data that is separate from the control portion of the object. This allows for the optimization of the signal-processing, facilitates the planned multi-threading of the FTS server by separating the signal-processing functions and data from the object, and provides several features including error detection. PD executes a signal-processing graph by iterating through a function call list in a manner that makes it possible to abstract portions of the graph. The implementation of the abstractions is very flexible and has the potential to be used to solve a variety of difficulties. Currently, this allows control of signal vector size and overlap, greatly simplifiying the use of algorithms that require a large number of samples.