Learning Cycling ’74’s Max presents a challenge even if you’re used to other music software. Is this new version easier to get to grips with?
The two previous releases of Cycling ’74’s flagship media toolkit — Max 5 and Max 6 — reimagined and redesigned the program’s user interface. Both times, the developers went back to the drawing board and looked in detail at how users encounter, explore and interact with the software, with a particular focus on new users. Clearly, however, Cycling ’74 are still not totally happy with the results, since the new Max 7 also features a reimagined and redesigned interface.
Max 7 isn’t just about aesthetics and usability, though. It also sports performance improvements, and comes with new, high–level media playback features, powerful file searching, tagging and packaging, and updated video and OpenGL support. And most significant for those who use it primarily as an audio tool is that at long last, Max has its own engine for pitch–shifting and time–stretching. (I’ll use the term ‘elastic audio’ as a convenient shorthand for these two distinct but related features.)
Some of us are old enough to remember when Max didn’t do audio at all; when the MSP audio component arrived in 1997, it was a paid–for add–on. In due course, MSP became bundled as an essential part of Max, as did Jitter, the video component. With Max 6 arrived another paid–for add–on called Gen, used for compiling audio and image components into efficient runtime form. Now Gen is also bundled, which means that a licence for Max 7 basically gets you everything (at least, in the Max application itself; Mira, the iOS multi–touch controller app for Max, costs extra money, as does Max For Live, which is technically an Ableton product).
Since a lot of what distinguishes Max 7 from Max 6 is interface design, these developments will be the main focus of this review. There are certainly things which Max 7 can do and Max 6 can’t — elastic audio and Live Device hosting are obvious examples in the audio realm — but most of the improvements are refinements of existing features such as performance improvements, better video support, additional audio file formats, and so on, or redesigns of existing functions. Since this is an audio magazine, I’ll mention video– and image–processing features only in passing.
Visually, Max has received another facelift. The basic interface scheme is relatively unchanged from Max 6: patcher documents present a graphical editing interface with the help of some supporting palette and toolbar machinery. But in Max 7, the toolbars have multiplied, and everything has gone a bit grey.
The new grey colour scheme caused me something of a Marmite moment. Greyscale design isn’t new: Ableton Live has a pale grey scheme by default, while Final Cut Pro X is pretty uniformly dark grey. In Max 7, though, the makeover feels slightly incomplete: while window toolbars and palettes are grey, window contents (such as help text) are pale or white. Moreover, the various grey areas of the interface seem to have slightly different hue values, giving the impression that they don’t quite match. Taste aside, there’s an overall feeling of a brutalist aesthetic at work here; the patching environment has a slightly more aggressive look than previously, with chunky boxes and icons rendered in pastel tones against a concrete–coloured background.
Arguably, it’s a little churlish to nit–pick about minor details of the interface. However, Max is a visual programming language, where the visual design is also part of anything Max is used to build, and the program is used by a community of people known for their strong design opinions and attention to detail. Many of us remember the move from Max 4’s pixel–box rendering to Max 5’s round–edged anti–aliasing, and the disquiet that caused in the ranks. (Ironically, as the screens show, most of the round edges have now been removed from Max 7’s object rendering.)
Having said all that, after a week or so’s use the new interface was second nature, feeling more warm and comfy than Max 6, and there are new options for customising colours and appearance, as we’ll see later.
To accompany the new grey look, practically all of Max’s user–interface objects have been redesigned. In line with the current fashion of eschewing skeuomorphic design elements such as reflective highlights, drop shadows and wood or metal textures, Max’s objects are now thoroughly utilitarian. The near absence of curved corners means that objects can be tesselated together into compact user interfaces — just as in Max 4, in fact — while the new minimalist style finally sees off some horrid bits of UI design like the look of Max 6’s VU meters, which seemed more suited to the Mac Plus that I owned back in the late ’80s.
The redesigned interface in Max 7 is an indication of deeper changes to the overall working approach, motivated at least in part by the fact that, in previous versions of Max, it was actually quite hard for beginners to perform elementary tasks which should be easy — and which are easy, or even automatic, in most DAWs. Case in point: most audio programs load the audio engine when you launch them, but in Max you have to turn it on explicitly. This makes sense in this kind of development environment, but in earlier versions it wasn’t clear how to do it. Max 7 makes it obvious, with a level meter and ‘power button’ at the bottom right of the screen. Likewise, playing back an audio file is easy in any other DAW, or should be, while Max has traditionally made the process opaque, to say the least: create an sfplay~ object (assuming you don’t mean groove~ or play~ instead), figure out how to attach an audio file to it, how to start it playing, how to connect the audio to the sound card... and how to turn audio processing on. In Max 7, new dedicated playlist objects make the process just about as easy as dragging a media file into a DAW.
The most significant workflow changes are reflected in the new toolbars. Some of these replace older user–interface machinery, such as what Max 6 called the ‘object explorer’, while there are new tools for browsing patchers, libraries and media. The sidebar panel survives for object properties, reference documentation and Max’s console/error window (which, after 25 years, is obviously a permanent Max feature; pop–up dialogues are still considered bad form).
Each of the four toolbars can be ‘unpinned’, which really just means auto–hidden. The top one bears the closest resemblance to the object explorer/palette in earlier Max versions, providing fast access to all the graphical objects, arranged by category, and a one–click button to get a new non–UI object. The top toolbar also provides appearance styling options, view scaling and documentation search. The selection palettes hanging off this toolbar are as brutalist in finish as the rest of Max 7, but are wonderfully clear, despite adopting a pastel colour scheme which doesn’t make immediate sense.
The left toolbar is home to a set of dedicated browsers which expose pretty much everything you might need in order to use Max. Anything displayed in any of the browsers can be dragged straight into a patcher document.
The file browser is the generic, all–purpose browser for all file–related Max content. A left sidebar arranges content by kind, by package (bundled libraries offering specific features), or by collection (user–extensible sets of files which can be created, edited and deleted dynamically). Items can be tagged, and text searches can drill down by kind, package, collection and tag. Collections can be created and deleted at any time, and files dragged into existing collections from the browser, or Windows Explorer or Mac Finder. A collection only contains references to files, not the files themselves, so a file may feature in several collections, and deleting a collection doesn’t delete its files. I was never a big fan of Max 6’s file browser, and considered it rather untidy and underpowered, but the Max 7 model is really the business, and I’m encouraged to start collecting, packaging and tagging my own material properly to make the most of it.
The object browser presents all of Max’s objects, categorised in such a painstaking manner that I suspect a librarian was involved in the process. The audio browser presents audio files categorised by length, which seems an odd metric but is probably suited to the way Max programmers use pre–recorded audio, though it would be nice to be able to use other categorisations such as file format or number of channels. Dragging an audio file into a patcher in Max 6 resulted in a menu prompt asking what kind of object should be used for it, which was not terribly friendly, but Max 7 instantiates a playlist object referencing the file (more on playlists later). Similarly, the video browser shows available video files and creates video playlist objects on demand, while an image icon makes static images available. (The media content presented is that which is bundled with Max, plus anything inside collections, or in Max’s search path.)
A paperclip button opens a browser for named ‘snippets’, an extensible library containing reusable fragments of patcher which can be dragged into patcher windows. At any time, a group of objects can be selected and saved as a new snippet. A plug icon opens a browser presenting all available plug–ins in the supported formats of VST, Audio Units and Max For Live Devices.
The ‘v’ and ‘b’ icons open browsers for Vizzie and BEAP, respectively. Vizzie is a library of high–level video processing patchers, originally added in Max 6 to provide fast–track access to Max’s Jitter video objects, while Berklee Electro Acoustic Pedagogy is a set of high–level modular synthesis patcher blocks developed as teaching material by Matthew Davidson. The BEAP components emulate a hardware modular synthesizer, but also have I/O modules to interface with actual CV/gate hardware, if you have a DC–coupled audio interface which allows this. Vizzie and BEAP are implemented purely in Max, so you can take them apart, reuse the bits in other patchers, connect them into Max For Live or stand–alone applications, and so on. Vizzie comes with an integrated help system, like the rest of Max; BEAP doesn’t yet, so you’ll have to search through the example files, or check the teaching material online.
The ‘star’ icon provides fast access to collections and their contents; you’ll have to use the full file browser to create, delete or edit collections themselves.
The bottom toolbar is relatively unchanged compared to Max 6: there are buttons for locking/unlocking the patcher, navigating between patchers, switching to and from presentation layout, showing the editing grid and debugging. An additional button captures any selected objects as a new snippet. The right–hand toolbar is new, but again most of the features it presents are familiar, including the object or patcher inspector sidebar panel, reference material, the Max console, as well as the new interactive lessons.
A new calendar–based browser presents a monthly, or linear ‘stream’, view of recently opened patcher documents, projects, help files and lessons — but not, apparently, media files. In practice, this is surprisingly useful and fits well with the way I develop material in Max — I often know what I was doing a day or a week ago, but not necessarily where to find all the files. Finally, at the bottom right, there are the already–mentioned audio on/off button and stereo VU/level meter. Solo and mute buttons can be added, but while audio on/off is global to the Max session, the other controls are patcher–local. There are no dB markings or peak indicators on the audio controls, which is a little surprising.
One more workflow improvement is that on launch, Max 7 opens patcher and documentation windows that were open last time it closed. Not a big deal, you might think, except that crash recovery is now part of the deal. If Max crashes, edits made to patchers up to the crash can be replayed, optionally, on relaunch. We’ve been used to this in Live for years, so it’s good to have it in Max as well at last.
So much for the ‘furniture’. What about the patching process itself? In overall terms, the basic procedure is unchanged — you create objects in the patcher and then connect them together with patch cords — but there are differences in the details. You can no longer just click an inlet to get a pop–up menu of attributes or messages for it: you have to right– or Ctrl–click. There’s no longer a status bar at the bottom of the window giving information about the selected pop–up item, and the floating ‘clue window’ no longer gives this information either.
I found the removal of these familiar visual cues irritating, but other, subtle, aspects of the patching process have been improved. There are new keyboard shortcuts for easily chaining objects together as they’re created, and patch–cord connections seem to fall into place much more naturally than in Max 6, which now feels somewhat like patching wearing boxing gloves. When objects connect, patch cords optionally give a little animation ‘wiggle’ as feedback and, overall, performance has been improved, so that Max 7 feels snappier and smoother than Max 6.
So far, we’ve looked at aspects of Max 7 which make it easier and faster to use, rather than anything which really provides completely new functionality. On the audio side, though, there’s something which is bound to attract attention: audio pitch–shift and time–stretch. Ableton Live users, and hence Max For Live users, have had elastic audio for years, but only as part of audio clip playback. Max 7 brings similar features directly into Max, and in real time.
These elastic audio features, which are built on top of the Dirac DSP library, are newly supported in a number of existing Max objects, but a couple of new objects are dedicated to them: pitchshift~ is a real–time, multi–channel pitch–shifter which takes a shifting parameter value, specified either in cents or as a rate, and outputs the shifted signal. The shift parameter can be provided via messages, or continuously as a signal. The pitchshift~ object reports its latency in samples, and on my system, the latency was a rather frightening 4096 samples. At 44kHz, that’s almost a 10th of a second, and there’s currently no way to force the latency down. On the plus side, the CPU load for the pitch–shifter is reassuringly low: on my month–old MacBook, I was getting hit with 1–2 percent of CPU per audio channel, which isn’t bad at all.
I was compelled to attempt an audio comparison between Max 7’s pitchshift~ and Ableton Live’s playback pitch-shifting, which is based on Zplane’s Elastique algorithm. The two processes affect the audio in rather different ways, although it’s obviously hard to quantify the difference. Both systems offer a range of quality settings; my feeling is that the lowest of Live’s settings sounds smoother and more natural than the equivalent Max algorithm, whereas the two ‘best quality’ algorithms seem more evenly matched. Live seemed better at preserving high–frequency tuned pitch when shifted down, while Max’s sound was a little sharper. In practice, though, it’s unlikely that you’d be in a situation where you’d be making a choice between one system and the other. For clip playback, Live offers convenience and low latency, while Max offers flexibility and real–time ‘live’ processing at the cost of high latency.
A close relation to pitchshift~ is retune~, a dual–purpose object capable of auto–tuning incoming audio, performing pitch detection, or both. The desired retuning, relative to a base note, is specified in two stages: a note list is presented as a scale, with values specified either in cent tuning or pitch ratio from the fundamental, or a mix of the two, whereupon integer lists can be passed in to specify indices to notes in this scale. Signal inputs can also be provided to lock the retuning to a specific pitch and/or detune value. The base note itself is specified as a conventional note name.
The pitch–detection mode of retune~ outputs the detected pitch as a continuous DC signal representing the detected frequency in Hz, plus signals representing note index in the scale and cent detuning from that note, and messages with scale note and cent detune to help with detecting note onsets.
The pitch–alteration and time–scaling machinery is also supported in, or affects, existing Max objects. A new stretch~ object references an audio buffer and destructively pitch–shifts or stretches the audio within it (without an undo option, although it can automatically reload a file from disk before each operation). Because stretch~ alters the audio samples in place, it’s not real–time, although the stretched audio can subsequently be accessed and played without any performance penalty.
Various objects have been upgraded to support pitch and time changes: the buffer playback object groove~ has a time–stretch mode which, when enabled, allows separate control of playback rate and pitch. Playback rate is, as in groove~’s normal operation, a signal, but for some reason, pitch–shift can only be input via messages. Similarly, the audio file player sfplay~ supports independent pitch and time control, as does the audio playlist object. And groove~ and stretch~ also take dictionaries of values as arguments, to do complex warping. A demo graphical editor allows Live–style ‘warp markers’ to be dragged around to set up the stretching parameters.
The elastic audio features offer massive potential, but (for me, at least) will take learning time to get a sense of their full potential when combined with everything else Max has to offer. It is wonderful, though, to finally have access to functions like this without having to resort to lower–level FFT processing.
Since Max’s development interface is also the interface for the things which are actually built with it, visual appearance is important. Max 5 brought in a sophisticated interface rendering layer, and with it comprehensive colour and transparency attributes for objects, but it also resulted in disparate collections of colour attributes for different objects. While most objects had a notion of background colour, level meters (for example) sported cold, tepid, warm and hot LED colours which were all customisable, while individual button LEDs had custom colours for ‘off’ and ‘on’, and text buttons had specific colours for mouse pointer hovering, and so on. Top marks for flexibility, but extra effort was needed when it came to applying a consistent colour scheme to a user interface as a whole.
Max 7 brings some rationale: a unified, simplified colour naming scheme which applies generically to all user interface objects except the specific Max For Live controls, which are unchanged. The scheme is backwards–compatible, so in almost all cases, objects still adhere to their original, specific colour properties. These are the ones revealed in the various attribute and inspector panels, but internally, they are mapped to common, generic ‘style’ names in a process referred to as ‘style mapping’.
A paint–tin button on a patcher’s top toolbar drops down a format palette strip. In this case a rotary dial is selected, so there are three colour properties that can be customised: Background, Indicator and Outline. Each is represented by an icon in the format palette. The graphic style of these icons is specific to each kind of object, and each icon accesses a set of colour palettes; there’s a palette of general background colours, one for highlights, and so on. The key concept is indicated in the title of this palette: a mapping from an object–specific name (in this case, Outline Color) to a generic style name (here, ‘elementcolor’). For comparison, a toggle tickbox doesn’t have an outline colour, so its ‘elementcolor’ is the colour it uses when unticked, or ‘off’.
So far, so good, but what does this scheme gain us? Well, since the style colour names are common, it’s possible to provide a customisable, extensible library of styles that works in a generic way across all objects. The leftmost end of the format palette sports a drop–down menu of style names, and a style can be applied to selected objects, or at the patcher level, to be reflected in all objects that haven’t been styled individually. Styling also includes text font and justification options, to be applied to any objects with a text component.
Although styling applies to objects, it doesn’t apply to patchers, so (for example) background colour isn’t part of the style machinery, even though colour–setting buttons are provided in the middle of the format palette. To set a default background colour, set it explicitly in a patcher and then save that as the default template for new patchers. This is also the technique to establish default editing grid behaviour.
There are some little bits of Max 6 colour customisation which don’t quite fit into the Max 7 scheme, and have therefore been deprecated. For instance, if you need distinct colour indication for your meters, you’re now forced to stick to the traditional green, yellow, amber and red, or use the Max For Live meters, which are still fully customisable.
Max 7 hosts VST and Audio Units plug–ins natively using the vst~ object, as Max has done since around version 4. In Max 6, the vst~ object supported a plug–in’s custom interface in a dedicated window, much like any other DAW, or could replace the custom interface with a generic window of sliders. In the patcher itself, vst~ was a plain object. Max 7 provides the same features as Max 6, but vst~ can provide the slider interface directly in the patcher, as an ‘inline view’. Dragging a VST or Audio Unit from the plug–in browser in the sidebar results in an inline vst~ instance. The vst~ object’s inline view presents a stack of sliders, each of which can be nudged up or down in the stack, or removed from the view completely, if the Edit Sliders mode is enabled. If a parameter slider is removed, it will reappear if the corresponding control if the interface window is moved. I’m reminded, predictably, of Live’s handling of plug–ins, where Live’s inline panel allows sliders to be added on demand for plug–in parameters. A minor, but niggling, difference is that Live picks up a parameter when a control is clicked in the device’s UI window whereas Max requires a click–and–drag. Another minor difference is that parameter changes in Max aren’t saved in the application’s undo history.
Another DAW–like enhancement to Max’s plug–in handling is that the current plug–in state can be captured as a ‘snapshot’ and saved, either as an external file, or directly into the enclosing patcher, to be reloaded or recalled later. Obviously, you can save as many snapshot files as you like — they are saved as text files, although the parameter content is encoded binary — but the patcher can only hold one snapshot state per vst~. Finally, and like Live, again, the slider view provides an on/off toggle at the top level, where ‘off’ equates to a full bypass for audio.
This kind of parameter snapshotting for plug–ins is also available for patchers themselves, which brings Max patchers more in line with how Max For Live devices are handled by Live, although the more versatile, Max–specific ‘attribute’ machinery is still present, just to add a little confusion.
As well as VST and Audio Units plug–ins, Max can host Max For Live devices thanks to a new amxd~ object, presenting them inline or in an external window. There’s no equivalent of the slider view, but otherwise devices are treated just like VSTs and Audio Units, even down to the snapshot facilities, and Max For Live devices known to Max are listed in the plug–in browser. A related feature, not clearly documented but mentioned in press announcements, is the ability to ‘author’ Max For Live devices without a copy of Live. This is supported for Max Projects — which is how Max for Live devices are represented internally — but not for patchers.
Since the majority of improvements in Max 7 are related to workflow and appearance, it is technically possible to take patchers written in Max 7 and open them in Max 6, as long as they don’t make any use of objects which are totally new to Max 7, such as playlists or stretch~, or Max 7 features added to existing objects, such as pitch–shift and time–stretch. Some experimentation suggested that such back–porting works pretty painlessly, although, predictably, colour styling information pretty much gets dropped on the floor in the process.
Why, though, would you want to run Max 7 patchers in Max 6? One reason might be Max For Live, where there’s good news and bad news. The good news is that Max For Live in Live 9.1.6 and later works quite happily with Max 7 as its runtime engine. In fact, since Max’s Live UI objects are basically unchanged from Max 6, Max For Live devices will look much the same as before. The bad news is that the current Max For Live release, as sold by Ableton, only includes authorisation for Max 6. To use Max 7, you’ll need to license it separately. Max For Live developers without Max 7 licences will have to wait until Ableton release a Max 7–based upgrade, not least so that new features will be available to their users.
I did some experimentation with Mira, the iOS app that networks sections of Max patcher windows onto an iPad, and it seemed to work fine, multi–touch and all, with only minor niggles involving tracking colour style changes, for which I’m told a fix is in the works. Mira itself hasn’t been updated, so controls still tend to resemble their Max 6 counterparts, but otherwise they’re functional. It goes without saying that a Mira upgrade supporting new features like playlist objects and inline plug–in panels would be most welcome.
Overall, Max 7 is an upgrade which takes rather a sharp turn in terms of appearance and workflow compared to Max 6. I was originally not that keen on the oppressive mixed–grey appearance, simplistic icons and blocky object rendering, and to be totally honest, I’m not sure I’m completely sold on the whole interface yet, especially since one or two bits of editing feedback in Max 6 have been removed.
On the other hand, the toolbars work very well, the patching process has been improved, the file browsers are very much in the how–did–I–manage–without–that category, and it’s now possible to style and format patcher controls without wasting an entire weekend. The playlist objects are a win for non–experts and handy for anyone who needs to play back media in a hurry, but for me the big step forward in terms of functionality is the ability to pitch–shift and time–stretch, something that’s been missing for far too long.
Historically, Cycling ’74 have tended to put out an initial major release and then spend time tweaking the details with the user community through a series of minor point releases. Max 7 still feels slightly rough, but it’s quickly growing on me, and in terms of features and usability I have very little to complain about.
Application installers have always struck me as a bit of a bodge, since applications should (in my opinion) take care of their dependencies and drivers automatically. And on the Mac, Max 7 doesn’t need an installer: simply drag it to the Applications folder, and the job’s done. Windows users, unfortunately, are stuck with a traditional installer. Adding packages or custom content inside Max’s application folder is now discouraged — in fact, on the Mac, Max doesn’t even have its own folder any more. Instead, custom content goes into a Max 7 subfolder of a user’s Documents.
As with earlier versions of Max, you get a 30–day grace period to use all of Max’s features before deciding whether to buy it, though you’ll now need an account on the Cycling ’74 web site to start this demo period. Before and after you activate the trial period, Max 7 will load and run patchers but won’t let you make changes. However, this ‘runtime–only’ Max is a massive improvement over the Max Runtime setup it replaces. Patchers can be unlocked, examined and edited, so long as you don’t mind changes being discarded when you quit. (You can always screen–grab an image of changes if you’re working on a temporary machine while your ‘real’ Max is elsewhere, and redo and save the changes by hand later.)
Another benefit of the ‘full’ Max in runtime mode is that the patching environment is complete: audio and MIDI setup windows are to hand, so you don’t have to hunt around for utility patchers to configure them, and Max Projects are fully visible. However, since you can’t save anything, sub–patcher ‘abstractions’ can’t be edited and reloaded into a main patcher, even though the main patcher itself can be (temporarily) altered. And Gen is constrained to runtime–only mode if Max isn’t authorised. Given that we have to accept usage restrictions in commercial software like this, the actual restrictions now imposed by Max are a lot more palatable than they used to be.
There’s also been a change, or rather an addition, to the purchase/licensing options. It’s still possible to pay up front and get a copy of the software to use indefinitely (with some finite sequence of bug–fixes and incremental upgrades), but now there’s also a subscription model whereby, instead of buying the software, you can take out a subscription and ‘rent’ it on a monthly basis. The precise details are, at the time of writing, still slightly unclear.
Max takes time to learn properly — arguably, longer than the 30–day demo period — and a ‘rental’ model lets people dip into it as and when they have the time or money to use a subscription. Speaking as someone who often teaches Max to beginners, it’s much easier to persuade the students or their institutions to take out a subscription during a course, or for a refresher, than to hope they haven’t used up their one–shot demo period. And for my own work, which often involves theatre and gallery installations, I can get a month of ‘full’ Max on a client’s machine at any time for the cost of a couple of beers, and then let the installation lapse to runtime–only once it’s ready, resubscribing temporarily if any snagging or alterations are needed — I (or the client) just need a dedicated email address for the subscription account. Obviously, dedicated users have to weigh up the overall cost of a long–term subscription versus the one–off purchase, but really, having both available is a definite bonus.
Recent versions of Max have been strong on learning by discovery, with linked tutorials, built–in help, bundled examples and so on. Max 7 continues in this vein, kicking off with a grand tour which delivers teaching material right inside the application. Unlike most documentation for other applications, the material is live: it actually runs, producing sound, connecting to a camera, processing video and fetching data from remote web sites. At the end of the tour there’s the option to jump into a set of lessons, each of which progresses step by step through a teaching video whilst inviting you to follow, building the example applications as you go.
The built–in documentation is organised in much the same manner as in Max 6, with tutorials, guides, more general ‘topic’ documents and reference pages for all of Max’s objects, but it’s become a lot smarter: the navigation’s better, there’s more cross–linking between topics, and the example code can now be dragged directly into patcher windows. The documentation system is built using an embedded version of Google’s Chromium browser, and hints at ever–closer integration between the ‘classic’ Max world and modern Web technologies.
For beginner users of Max, the simple job of playing back audio and video files has always been inexplicably complicated — until now. New in Max 7, playlists are intuitive, graphical media players which also solve the problem of what to do when someone attempts to drag a media file into a patcher. This is an action that makes sense conceptually, but until now, Max hasn’t had a sensible response to it.
Apart from the fact that they support different kinds of media, audio and video playlists are essentially identical in appearance and function. A playlist presents a stack of media files, each laid out graphically as a waveform (audio) or sequence of thumbnail images (video), flanked on the left by play/stop button, loop enable switch, and an optional drag handle for reordering the files. Drag a media file into a patcher window, and you get a playlist containing only that file. Additional files can be dragged into, and added to, an existing playlist, although some care is needed: dragging onto an existing file, rather than into a gap between one file and the next, replaces the target, and since the dragging operation isn’t treated as a ‘real’ editing operation, it can’t be undone.
There’s no horizontal scaling, zooming or scrolling, so the width of the playlist object represents the entirety of each file, but it is possible to click and drag to select a portion of each file, which gets outlined in red. Audio and video scrubbing are also supported, while Command or Ctrl+Alt–clicking allows the selected region to be dragged, making for continuously looped scrubbing if the file is already in looped playback. The scrubbing sounds clicky, as does the looping — there’s no crossfading or other niceties — so for a more polished effect you’d have to code your own solution. Despite the use of the name ‘playlist’, there’s also no Ableton–like follow–on cueing from one file to the next, but since playlist objects output messages when files stop and start, you can wire up your own cueing system without too much trouble.
Playlist status information such as file names, selection points and loop options is saved in the patcher, and can also be exported as a dictionary message, to be processed elsewhere in Max. However, there’s no easy way to feed a dictionary back into a playlist to restore a saved state. Although there are no explicit interface controls, both kinds of playlist support variable–speed playback via messages; the audio player also pitch–shifts and time–stretches, and supports multi–channel audio files.
While we’re on the subject of file playback, Max can, at long last, now load and work with compressed formats such as MP3 and FLAC. Compressed files can be loaded into the sfplay~ and playlist~ audio players, but also into buffer~ objects in RAM, to be manipulated by objects such as play~ and groove~.