Month: October 2012

From the Pd manual

http://puredata.info/docs/manuals/pd/x5.htm

5.3. differences from Max/MSP

It wasn’t anyone’s intention to make Pd a Max/MSP clone, but on the other hand, if there’s no reason for a feature to appear differently in Pd than in Max/MSP, the choices in Pd tend to hew to those in Max/MSP. Moreover, some effort has been undertaken (but more is needed) to make the two interoperable.

You can use Pd to import and export patches to Max/MSP; just save as text to a file with extension “.pat”, and then open it in Pd. You’ll at least get something. If you stick to common or commonizable features you can actually develop patches for both platforms.

When specific objects exist on one platform and not on the other, it’s often possible to make abstractions to imitate the missing objects, in a kind of personalized compatibility library.

There are, however, differences in semantics you’ll want to know about; a partial list follows.

abstraction arguments. In Pd you can edit instantiations of abstractions and save the result back to the file of the abstraction. This isn’t possible in Max, because the instantiations are different from the abstraction itself in that “#1”, etc., are replaced by the instantiation arguments. In Pd, these arguments appear as “$1”, etc, and are translated at a slightly later stage of the instantiation process so that you still see them as “$” variables in the instantiation. (see Section 2.7. abstractions)

In Pd, to make current all instantiations of the abstraction, either delete and recreate them or close and open the patch; this is done automatically in Max/MSP.

In Pd, if you select “save” while in a subpatch, the parent is saved. In Max/MSP, if you do this a dialogue box comes up asking if you want to save the subpatch as a separate file. (if you want to save a subpatch to a file in Pd, you have to copy and paste the contents to a new document.

In Pd, inlets and outlets are ordinary text objects; in Max/MSP they’re “gui” objects from the palette.

In Max/MSP, if an object’s outlet is connected to several destinations, corresponding messages are always sent in right-to-left screen order. In Pd, the messages are sent in the order you made the connections in. In either case, in situations where you care about the order it’s appropriate to use a “trigger” object to specify.

In Pd, there’s no “gate”; instead it’s “spigot” with the inlets in the opposite, more natural order.

Switching subsets of the DSP patch on and off is done in completely different ways in Pd and Max/MSP, and block sizes are handled differently as well.

Max offers many “GUI” objects such as sliders, dials, VU meters, piano keyboards, even “bpatchers.” Until version 0.34, the only two in Pd were the number box and graphical arrays. Starting in version 0.34, Pd incorporates Thomas Musil’s GUI objects: sliders, switches, and so on. (Thanks Thomas!) Beyond this essential collection of GUI objects, it’s unlikely you’ll ever find any commonality between the two. Also, as of 0.34, importing and exporting to Max doesn’t know about the Musil objects; I’ll try to get that fixed for 0.35.

In Pd there’s no “preset” object (I now think it’s basically a bad idea) and you have to use explicit sends and receives to restore values to number boxes. Then just make a “message” box to re-send the values you want.

In Macintosh land, instead of getting tabosc4~ and arrays, you get cycle~ and buffer~. The only gotcha is that you probably can’t draw in buffer~ with the mouse as you can with arrays, but at least it’s possible to make a patch that copies a “table” into a “buffer~”.

The “bpatcher” feature in Max has a correlate, “graph on parent” subpatches, in Pd; however, Pd’s version is quite different from Max’s.