Nov 23, 2006 at 6:17pm
I was just bitten by a problem Max has had since time immemorial:
I hope that some future version of Max more closely follows the
Nov 24, 2006 at 12:05am
On 23-nov.-06, at 19:17, Chris Muir wrote:
> I was just bitten by a problem Max has had since time immemorial:
When I complained about that years ago, I was told it was a feature.
Nov 24, 2006 at 1:56am
>> I was just bitten by a problem Max has had since time immemorial:
This feature has both bitten and aided me in the past. Bitten, I
I can think of several ways to change this behavior for the better,
- A preference setting to toggle the behavior.
- A warning when about to save a patcher over a file whose contents
- Make [onecopy] work everywhere, not just in the Extras menu. I
I feel you on the frustration, though. I think I have uttered the
Nov 24, 2006 at 4:53am
> – Make [onecopy] work everywhere, not just in the Extras menu. I
I highly second this feature request!!
Nov 24, 2006 at 6:09am
funny, this exact thing happened to me while performing in Paris this
*but I also agree that it would be nice to put [onecopy] in a patch
On Nov 23, 2006, at 8:53 PM, Philippe OLLIVIER wrote:
Nov 24, 2006 at 10:39am
On 24-Nov-2006, at 2:56, Vlad Spears wrote:
> – Make [onecopy] work everywhere, not just in the Extras menu.
Actually I’ve done this with a new Litter Power object. It still
At least you get more standard window behavior.
Argus will be in the next Starter Pack. Litter Pros are, however,
> Aided, because I was able to open a second instance of a patcher
In this sort of situation I would drop to the Finder, duplicate the
> More importantly, I’ve also used this to open up multiple instances
I would also just as soon duplicate the document for this. Or
————– http://www.bek.no/~pcastine/Litter/ ————-
Nov 24, 2006 at 11:08am
Quote: Peter Castine wrote on Fri, 24 November 2006 11:39
> > Aided, because I was able to open a second instance of a patcher
I agree. It is worth a lot to standardize basic behaviour in tools-world. The standard is that you duplicate your file if you want to open it twice. I believe Max should abide by this standard.
Nov 24, 2006 at 11:11am
On Nov 24, 2006, at 2:39 AM, Peter Castine wrote:
>> – Make [onecopy] work everywhere, not just in the Extras menu.
Ha! I am a Litter Pro! Serves me right for waiting until it’s out
Nov 24, 2006 at 11:13am
On Nov 24, 2006, at 3:08 AM, Mattijs Kneppers wrote:
> I agree. It is worth a lot to standardize basic behaviour in tools-
A preference toggle for this behavior would make everyone happy…
Nov 24, 2006 at 11:49am
Vlad Spears wrote:
That can’t hurt, in my case it would be always keeping the existing
> – A warning when about to save a patcher over a file whose contents have
This should be a must, it could only ask if a newer version hasn’t been
Another approach could be to automatically undirty all other open
Maybe the easiest would be to put up a common “shall I overwrite this
> – Make [onecopy] work everywhere, not just in the Extras menu. I would
That is a very logical, obvious and clear request, I can’t express how
It would make Max more consistent.
A global onecopy would also safely prevent very big performance patches
Nov 26, 2006 at 4:55pm
Mattijs Kneppers wrote:
Then Max doesn’t need to be changed (I want to be able to open several
And beside that, backup, backup, backup…
Nov 26, 2006 at 7:25pm
At 5:55 PM +0100 11/26/06, Stefan Tiedje wrote:
Could you elaborate on your use case for the current behavior?
I can’t really think of a good reason to allow two (or more) of the same patcher to be opened for editing, and for each to have their own edit state. The best reason I’ve heard so far is so that chunks can be pulled out of the older, saved, version while editing.
The way I would like to see this behavior changed is that:
>And beside that, backup, backup, backup…
Yeah, but backups are mostly useful for disk-related problems, and this problem is arguably one of user error.
I wouldn’t mind having Max add an auto-backup feature, though. Something like every time a file is opened for editing, a backup is created in some backup destination of the user’s choosing. There would have to be some sort of file renaming for name-space collision avoidance, but that’s not too hard.
Nov 26, 2006 at 7:43pm
Any sysadmin worth his or her salt will tell you the majority of the
Sorry for the OT post.
Regardless. I have also lost data due to the multiple patchers having
I do like the ‘bring one version to the front and edit only one
v a d e //
On Nov 26, 2006, at 2:25 PM, Chris Muir wrote:
Nov 26, 2006 at 8:42pm
On 26 Nov 2006, at 19:25, Chris Muir wrote:
All of which brings up my pet beef with MacOS. I am often working on
Nov 26, 2006 at 8:46pm
At 2:43 PM -0500 11/26/06, vade wrote:
I agree with that, but I can’t see user created backups helping much here, though. The problem created by the multiple instances of a patcher open for editing (MIOAPOFE :-) ) bug/feature happens on such a micro time scale (editing and saving patchers in a single session), that user created backups would not be much help, at least in my case.
>Regardless. I have also lost data due to the multiple patchers having multiple edited states ‘issue’, but having more than one version of a patcher open and running is very powerful, and id rather not loose that.
Yeah, I’ve never argued against that. I do that all the time.
>I do like the ‘bring one version to the front and edit only one instance’ rather than a few solution.
One edit instance seems to be the way to go, at least to my way of thinking.
Nov 26, 2006 at 10:12pm
On Nov 26, 2006, at 11:25 AM, Chris Muir wrote:
> I wouldn’t mind having Max add an auto-backup feature, though.
FWIW, with Apple’s Time Machine in Leopard, and similar built-in
I appreciate user frustration w/r/t multiple versions open for
Nov 27, 2006 at 1:54am
At 2:12 PM -0800 11/26/06, Joshua Kit Clayton wrote:
Good point. That will probably be the best solution.
>I appreciate user frustration w/r/t multiple versions open for editing, and it is something for us to consider for Max 5, though no promises. There are lots of things we’re working on for Max 5 and this isn’t the largest of our priorities. There are cases both for and against. One of the largest case for, is that it’s been this way for ~20 years, and no matter what the “right” solution is, changes in application behavior do have a significant cost to familiar users. There’s a good article on this on the Vista UI team’s blog.
I certainly understand that this isn’t, and certainly should not be, at the top of any priority-sorted list. That said, canonizing what has always been tantamount to a bug, just because of longevity, seems unwise. I’m sure I’ve been whining about this one in some fashion or another since before Max found a home at Intelligent Music, much less Opcode or Cycling74. I don’t get bitten by it too often, but when I do, it’s really annoying, if only because Max flies in the face of pretty much every other application with this behavior.
I’ve still not heard a good use case for the current behavior. I would bet many more people would be served by a “only one copy for editing” approach, than would be inconvenienced by having to use a new method for grabbing parts of a patch that they’ve deleted.
I’m really not trying to make a big deal of this, it just always struck me as something that would be fairly easy to change.
Nov 27, 2006 at 12:53pm
> Good point. That will probably be the best solution.
The obvious techie solution is to run a version control system. (I’ve
> I’ve still not heard a good use case for the current behavior.
A Max patcher is a processing object, not a passive chunk of data, so
In other words, the current functionality, while nonstandard and
> I would bet many more people would be served by a “only one copy
That makes sense to me, but it’s still different to the standard
nick rothwell — composition, systems, performance — http://
Nov 27, 2006 at 7:00pm
Nov 27, 2006 at 9:56pm
Another vote for only allowing one copy at a time to be opened for editing. I’ve lost work this way myself…
Nov 27, 2006 at 10:29pm
Peter Castine’s Litter object lp.argus does the trick! :)
On Nov 27, 2006, at 1:56 PM, Dan wrote:
Nov 28, 2006 at 10:45pm
Chris Muir wrote:
Not for editing, but for using. As Max doesn’t make a distinction
> The way I would like to see this behavior changed is that: When you
As preference I would welcome it, I would never activate it though…
>> And beside that, backup, backup, backup…
But that user error will overwrite an existing patch, you might find the
Backups help in 999% against user errors, broken or stolen hard drives
You must be logged in to reply to this topic.