MaxMSP Macintosh specific FAQ

Why is "Loading CFM externals disabled" on my Intel Mac? Can I install support for these externals?

If you are running MaxMSP 4.6 on an Intel Mac, you may have discovered an error message that says "Loading of CFM externals disabled". This means that you are trying to use older third-party externals in your patch that have not been updated for Universal Binary compatibility. Because MaxMSP is a UB application, you will not be able to run older "CFM" externals. You will need to look for Universal Binary or Intel native updates for these objects. These can often be found on the developer's personal website, maxobjects.com, or on the MaxMSP forum.

If you are using a PowerPC Mac, you may install support for CFM externals by running the installer located inside of the MaxMSP application bundle. We provide this compatibility as a convenience to PowerPC users, however due to various changes in the application itself and the locations of various libraries, you may still need an updated external. As always, you will need to contact the developer for information and support for third-party externals.

What are the main differences between OS 9 and OS X versions of Max/MSP?

Here is a brief summary of the major differences:

• OS X doesn't use OMS (Opcode MIDI System) -- the OMS objects are no longer in the 4.2 distribution. Instead, OS X handles MIDI functions using its own built-in Core MIDI; it's very much like OMS, but also includes built-in virtual sources and destinations for communicating MIDI between Max and other applications.

• The Sound Manager and the use of ASIO drivers have been replaced by OS X's built-in Core Audio, which handles audio interfacing for both built-in audio and third-party audio hardware. This means that if you're using any external hardware that used ASIO drivers, you'll need to check the manufacturer's website to download and install Core Audio equivalents to use your hardware with OS X.

• External objects are now located in the folder /Library/Application Support/Cycling '74, shared by all copies of Max/MSP: You can drop a folder into this folder and it will be included in the Max "search path" the next time you launch the application.

• Building standalone applications uses a new Max/MSP object and a simpler one-step process: Just add a copy of the new standalone object to your patch, use its Inspector to specify the options for your application, and choose Build Collective / Application from the File menu.

• There is no direct support for CD audio in Max/MSP 4.2 -- the cd and cd~ objects have been removed. Use the MSP sfplay~ object to open CD tracks as audio files instead. It's more powerful than cd or cd~, and lets you do things like playing CD tracks backwards or at different speeds.

• There is no MIDI enable/disable button in the Max 4.2 patcher window, and the lock/unlock button is the "pill" on the right side of the title bar.

• Max 4.2 can handle OS X files that have no OS 9 "type/creator" information, provided that they have the proper filename extension -- for example, files ending in .pat are Max binary files and files ending in .txt are treated as text files (Note: filenames that have those extension can be used successfully as subpatch names without including the extension in the OS X version, but not under OS 9 (version 4.1)).

How do the OS 9 and OS X versions of Max/MSP compare in terms of speed?

OS X is a completely different OS than OS 9. A part of that difference involves higher system overhead. In addition, it's no longer possible for a single application to entirely take over system resources. As a result, don't expect OS X performance to be identical to OS 9 -- some things are faster, some things are slower. We're working on improving OS X performance and we hope that future updates will be even faster.

Will my old patches from OS 9 work in the OS X version?

It will depend on the external objects you use in your patch. If you're using objects that are in the OS 9 distribution but not in the OS X version (such as any OMS objects), you'll have to replace them with their OS X equivalents.

If you are using third-party external objects (objects that are not part of the standard Max/MSP distribution), the OS 9 versions may not work under OS X, and may need to be replaced with OS X equivalents.

How will I know whether a third-party OS 9 object doesn't run under OS X?

While many OS 9 third-party objects will run without error under OS X, you'll need to find an OS X version of an object if you see a "can't fragload" error in the Max window when you attempt to use it. In particular if the "can't fragload" error mentions InterfaceLib,MathLib, SoundLib or other OS 9 only libraries.

How can I find out if OS X versions of third-party objects are available?

You can find a listing of third-party objects available for OS X here, along with a report by someone who's actually checked to see what OS 9 third-party externals currently do seem to work. maxobjects.com is also a great resource for finding out about various third party objects.

I made a standalone application/collective for OS 9. Will I need to recompile it to run under OS X?

Yes, you will. Be sure to check that you aren't using OMS objects or objects, objects that aren't in the Max/MSP 4.2 (or later) release, or third-party objects that do not run under OS X. Happily, making standalones is now easier.

If I make a patch in OS X will it work on OS 9?

The answer is similar to that for running OS 9 patches under OS X. You'll need to replace any Core MIDI objects with OMS equivalents, check to see that you're not using any Max/MSP 4.2 (or later) objects that were not part of the standard Max/MSP OS 9 distribution, and verify that there are OS 9 equivalents to any third-party objects you use.

What Max/MSP 4.1 objects are not in the OS X version?

cd, cd~, omscontrollers, omsinfo, omsnotes, and omspatches.

Does the OS X version take advantage of multiple processors?

Max/MSP doesn't break audio tasks up and distribute them across multiple processors -- if you only consider the audio part of Max/MSP, there is no additional benefit to using multiple processors. Since OS X is a "threaded" OS, some applications (e.g., Logic Audio) make use of multiple processors by running some application code (e.g., MIDI and UI tasks) as one thread on one processor, and audio on another processor. While Max/MSP doesn't explicitly control how OS X distributes these threads across processors, there are some things you can do to realize some benefit from multiple processor systems.

There are three parts of Max/MSP that can potentially run in their own threads. Audio code and UI tasks run in their own threads, so it is possible that OS X can move the audio to the second processor while the UI remains on the first. The Max/MSP scheduler can be set so that it either runs in its own thread, or run in either the audio or UI task threads using the DSP Status window (found in the Options menu):

• If "Max Scheduler in Overdrive" is off, the scheduler will run in the same thread as UI tasks.
• If "Max Scheduler in Overdrive" is on AND "Scheduler in Audio Interrupt" is on, the scheduler will run in the same thread as the audio code.
• If "Max Scheduler in Overdrive" is on and "Scheduler in Audio Interrupt" is off, the scheduler will run in its own thread.

You can use these settings to optimize the use of multiple processors, depending on what kind of UI and scheduling tasks your patch requires.

If you're running Jitter, it's important to know that Jitter processing typically takes place in the UI thread, and it seems that some Quicktime codecs support the explicit use of multiple processors to decompress frames.

Will one install work for both OSs on a dual boot system?

No. You must have Max/MSP 4.1 installed under OS 9 and version 4.2 (or later) installed for OS X.
to top