Changing behavior of a released object

Jan 2, 2014 at 2:57pm

Changing behavior of a released object

I was working on some upgrades to my rm.slice MXJ I noticed there is a mistake in my original version of the algorithm. My first instinct was to fix this but leave behind the option to activate legacy mode via an attribute. I then realized that even though the correct algorithm would be better, this may change behavior of existing patches for the few users of this object.

I guess I could have two behaviors in the object with the original as default and the improved version selectable via an attribute, but this would put new users of the object at a disadvantage if they don’t realize to try the improved algorithm by setting the attribute.

So is my best option just to keep the current object as is and release a new rm.slice2 or something? Anyone have any other suggestions for this type of issue?

Jan 2, 2014 at 5:23pm

if it’s an mxj object then it will only affect those who replace the old .java and .class files with the new ones– if they are consciously replacing the files, then they would be aware of the differences, and presumably repatch accordingly. So I would keep the original name and include a readme text file with the distiribution to explain the ‘silent’ update (also incl a modified help file which also explains the difference). And modify the code so the default algorithm is the better one, and ignore (don’t include) the old algorithm. I guess that’s against best practise regarding pure java but with max-java I believe it would be acceptable given the context and relatively small user base.

Jan 2, 2014 at 10:17pm

It is distributed in a jar, but I see your point. Would you feel the same if it was a external object written in C vs Java? Or for an abstraction? Or a Gen patch? The question came up for me for an MXJ object, but stands for Max object/abstraction/gen development in general. I remember at the Cycling ’74 Expo in New York a couple years ago quite a few questions about the odd behavior the arguments/etc of a few of the standard Max was answered with: so we don’t break old patches.

I was originally planning to handle it how you propose, but when I release this object I am also going to make it available as part of a larger library available in a single jar. Other collision issues aside, this made me start thinking such an approach may not work as well as it seems.

Even though I think there are only about 10-15 people using this object (maybe I’m wrong!), I’m flattered when other people find my code useful and I don’t want to be a jerk and break their patch.

Any other votes?

P.S.: I began distributing this to the public about 2 years ago, and to some friends 2 years before that if this plays into anyone’s opinion.

Jan 2, 2014 at 11:36pm


That’s something i often ask myself. Is it worth the cost to maintain compatibility (and all the mess it implies) specially after fixing bad choices or errors in algorithms?

There is pro & cons. The gap between python 2/3 is a situation where that kind of things have been discussed a lot. Another situation nearest the max community is SuperCollider. I follow the dev team on github and support for OS X 10.6.8 seems to have been dropped. That’s hurt me as i’m still using that OS (and plan to test SC in the future). But TBH i understand that choice at least if nobody cares to spend time to maintain that compatibilty. IHMO (when you do it for FREE) it is just a time/feedback equation.

My 2 cents:

- Always prefer consistency vs messy workarounds.
- Contact all your known users to warn about the change.
- Write it clearly in the change log.
- Tag your releases accordingly.

Jan 3, 2014 at 4:35am

In general I would never change existing behavior, but rather add an option or attribute for switching to the new behavior. For any existing object there is an unknown and constantly increasing number of patches using that object. Nobody is going to update all those patches, no matter how much you beg and plead, and if a patch stops working correctly, you’ll get the blame.

That said: consider exactly in what ways your proposed change to behavior will actually effect patches. For instance, if your “fix” is only going to change behavior in relatively exotic configurations (and the old behavior was in some way clearly “wrong” or “buggy” in those situations), there is a reasonable chance that users will actually be happy when the behavior of their patches is changed for the better.

This may not be a decision to make lightly. (And what Nicolas said about documenting and communicating the change.)

Jan 4, 2014 at 3:56am

At the moment you use 3rd party externals in a patch, that implies it will not be valid “ad vitam aeternam”.

Even if cycling’74 takes care of backward compatibilty for antic formats, most of the 32-bit externals will never be updated to 64-bit, most of them will never be ported to follow Apple psychotic release cycle. So if a user care about legacy patch preservation my advice would be to only use native objects.

And even in that case, that’s not so easy. For instance, switching from Max 4 to Max 5 makes most of my patches unreadable (unmaintainable) due to default font size values and other presentation presets. I guess i could write an executable to parse and reformat them, but i doubt that i will do it a day. Somebody has done it before?

I’m always surprised by praises to backward compatibility (specially to preserve failures and/or bad choices in the design that tend to inconsistency), while at the same time, hardware compatibility is most of time removed without any remorse. But of course that’s only my opinion, and honestly, Peter’s advices are mostly shared by gurus, and by most of (yours) Max users ;-)

Well, it appears that “document and communicate your choice”, defines the consensus.

Jan 6, 2014 at 8:58am

Thanks for your feedback everyone.

Jan 7, 2014 at 4:45am

Even sticking to factory objects is no guarantee of ad vitam aeternam. There is a significant number of objects from the earlier (official) Max releases that have eventually been orphaned. Just recently I was revisiting a performance patch that made extensive use of the [graphic] & friends objects.

Yeah, sure, Jitter is much cooler and can do much more, but [graphic] could do some quite useful stuff with a small fraction of the resources. Basically, almost anything I did in Max 3&4 needs to be re-written from scratch. Ironically, I have a number of Third Party Objects with longer life cycles.


You must be logged in to reply to this topic.