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.

Thanks for the reply ///

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

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.....

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

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:-

pattr.mxe scale.mxe pictctrl.mxe jit.ameba.mxe pattrstorage.mxe jit.pwindow.mxe jit.alphablend.mxe jit.window.mxe jit.brcosa.mxe zl.mxe pipe.mxe rslider.mxe dropfile.mxe

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.

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.

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

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...

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?:-

Max: attrui dict family (13 objects) error getattr join jstrigger override routepass unjoin

MSP: filterdesign filterdetail fzero~ frameaverage~ framesmooth~ gen~ plot~ polybuffer~ scale~ (long awaited)

Jitter jit.axis2quat jit.euler2quat jit.quat2axis jit.quat2euler jit.phys family (9 objects) jit.anim (3 objects) jit.gen jit.gencoords jit.gl.camera jit.gl.light jit.gl.lua jit.gl.material jit.gl.node jit.gl.path jit.gl.picker jit.gl.pix jit.gl.physdraw jit.gl.skybox jit.mgraphics jit.pix

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)

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

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.

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.

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.