Forums > MaxMSP

Opening Max 6 files in Max 5

Dec 10 2012 | 8:56 pm

Hi there,

Through testing with the demos: 5.1.9 seems a lot more stable that 6.0.8.

I’m planning to buy 6, and use 5 at the same time, and would appreciate some community feedback.

My question is:-

How do version 6 patches operate in version 5. Are the newer files generally compatible with the older Max (version 5)?

Dec 10 2012 | 9:59 pm

In my experience, there aren’t any problems; you have some problems if you had to do the inverse (open max 6 patches with max 5), but are only minor stuffs. At the beginning I wasn’t really sure to upgrade, but max 6 have some really cool feature that speed-up the work and help to keep your patch in order.

Dec 11 2012 | 12:37 pm

Thanks for the reply ///

That’s what I was asking: opening max 6 patches with max 5…….

Dec 11 2012 | 1:26 pm

There seems to be a partial(?) list here of new v6 objects:-

So just taking these into account, hopefully there should not be any other issues.

Please reply if have any other info to add. EG: general running issues etc…..

Dec 11 2012 | 1:39 pm

I did try to open a Vizzie patch created in v6 in v5 and it didn’t open properly. Lots of errors ….

Dec 11 2012 | 1:46 pm

It looks at those all these Vizzie / Jitter related objects (plus more?) were changed in V6, and V6 created versions do not open properly in V5:-


Dec 11 2012 | 3:17 pm

The patcher format is, AFAICT, identical between Max 6 and Max 5. That being the case, Max 6 patchers can be read with Max 5 and the *only* issue is whether the external objects referenced in a patcher are available. This is, btw, also an issue when 3rd-party objects are used in patchers. And, as Curveau points out, that the external objects haven’t been modified in ways that make them backwards-incompatible.

I’m a little surprised at several of the objects Curveau lists above—Cycling ’74 (and most 3rd party external developers) take care not to introduce new features that break compatibility in any direction. I know some Jitter objects have been a bit naughty in this regards, particularly by adding new attributes. But [pipe] or [scale] ought not to have been problems (for instance). Can you be more specific about the issues you’ve had?

In a pinch, you can possibly replace the older version in your Max 5 search path with the newer version from your Max 6 distribution. Note that there may be some issues because the newer API provides enhanced features that Max 5 doesn’t have. But, again, it seems a little unlikely that simpler objects will be making use of new API calls. As always, YMMV.

Dec 11 2012 | 5:22 pm

Hi Peter,

I’m not sure what you mean by ‘……… replace the older version in your Max 5 search path with the newer version…………’

As to the errors: when loading the attached patch (on Windows x64) I get 10+ error windows pop with various messages regarding the aforementioned files.

Dec 11 2012 | 5:23 pm

Ok, too big to attach :)

As far as those two files are concerned, the errors read:-

The procedure entry point str_tr could not be located in the dymnamic link library C:……AppDataLocalTempMaxscale.mxe

The procedure entry point clock_new_withscheduler could not be located in the dymnamic link library C:……AppDataLocalTempMaxpipe.mxe

Dec 11 2012 | 9:22 pm

You can’t copy the externals for Max 6 and use them in Max 5 as you discovered. Some of them might work but some other might use some new functions that are not in Max 5.

In general using a patch made in Max 6 works in Max 5 unless you use specifically new objects or new features of some object (scale, zl for instance have been enhanced in Max 6), and more…

Dec 11 2012 | 9:55 pm

Thanks for the response Emmanuel….

It would be really helpful if there was a specific list of objects that are V6 only.

Is this (earlier posted) list pretty much it?:-

dict family (13 objects)

scale~ (long awaited)

jit.phys family (9 objects)
jit.anim (3 objects)

Not new but much improved :
poly~ (anti-aliasing filter when upsampling)
vst~ (opens AudioUnit plug-ins too)
cycle~ (size and position in buffer~ set freely)

Dec 12 2012 | 10:14 am

It’s pretty much it, but the list of improvement within the object themselves is hard to figure out.

Dec 12 2012 | 11:28 am

That’s a shame, as it seems important for backwards compatibility. Also, because of the inherent instability of nearly all (new release) software (not exclusive to Max), it would seem like a given that there would be some mechanism (conversion) in place to use older versions, if needed.
Of course, this would also be very useful people wanting to simply open a newer created file in the previous version too.

Dec 14 2012 | 3:59 pm

As far as I know, the only way to track changes to an individual object is to read through the "What’s New" documents included with the individual Max/MSP/Jitter updates, looking for mentions of the object you are interested in.

There are a lot of "What’s New" documents to look through. Even with clever grep/regexp it is a daunting exercise.

It would be Really Great™ if Cycling ’74 would institute a convention of adding a History section to the documentation of each object, with the goal of adding a note with the current release number whenever a significant new feature is added (particularly, whenever backwards-compatibility is impacted). Even if it doesn’t include the history of the last twenty years, if the convention were started now a lot of people would be grateful a few years down the road.

Dec 14 2012 | 4:02 pm

You can’t copy the externals for Max 6 and use them in Max 5 as you discovered. Some of them might work but some other might use some new functions that are not in Max 5.

I did say "Your Mileage May Vary." And the only way to find out which externals do work is by trying them out. I didn’t guarantee success, but was suggesting an approach that might, possibly, with a lot of luck, at the right phase of the moon and keeping your left-hand fingers crossed (have I put in enough disclaimers yet?-) work.

Viewing 15 posts - 1 through 15 (of 15 total)

Forums > MaxMSP