Aargh

Nov 23, 2006 at 6:17pm

Aargh

I was just bitten by a problem Max has had since time immemorial:
having multiple windows open for the same file. I can’t think of
another application that allows the user to have multiple windows
open editing the same file, each with their own edit state. This is a
recipe for disaster that I have generally taught myself to steer
clear of, but when quitting Max with a bunch of windows that need to
be saved, but some that don’t want to be saved, it’s easy to get
careless.

I hope that some future version of Max more closely follows the
document editing paradigm used by the rest of the civilized world.

-C


Chris Muir | “There are many futures and only one status quo.
cbm@well.com | This is why conservatives mostly agree,
http://www.xfade.com | and radicals always argue.” – Brian Eno

#28853
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:
> having multiple windows open for the same file. I can’t think of
> another application that allows the user to have multiple windows open
> editing the same file, each with their own edit state. This is a
> recipe for disaster that I have generally taught myself to steer clear
> of, but when quitting Max with a bunch of windows that need to be
> saved, but some that don’t want to be saved, it’s easy to get
> careless.
>
> I hope that some future version of Max more closely follows the
> document editing paradigm used by the rest of the civilized world.

When I complained about that years ago, I was told it was a feature.
But it’s still extremely annoying, and already made me lost many
hours…

p

#88954
Nov 24, 2006 at 1:56am

>> I was just bitten by a problem Max has had since time immemorial:
>> having multiple windows open for the same file. I can’t think of
>> another application that allows the user to have multiple windows
>> open editing the same file, each with their own edit state. This
>> is a recipe for disaster that I have generally taught myself to
>> steer clear of, but when quitting Max with a bunch of windows that
>> need to be saved, but some that don’t want to be saved, it’s easy
>> to get careless.
>>
>> I hope that some future version of Max more closely follows the
>> document editing paradigm used by the rest of the civilized world.
>
> When I complained about that years ago, I was told it was a
> feature. But it’s still extremely annoying, and already made me
> lost many hours…

This feature has both bitten and aided me in the past. Bitten, I
lost a bunch of work because I saved a much older version over the
newer. Aided, because I was able to open a second instance of a
patcher and copy a portion I had deleted and moved well on from. It
was easier than the save-as dance, by far. More importantly, I’ve
also used this to open up multiple instances of the same patcher to
create musical systems…. it’s fun.

I can think of several ways to change this behavior for the better,
but I don’t really want it gone.

- A preference setting to toggle the behavior.

- A warning when about to save a patcher over a file whose contents
have changed since the to-be-saved patcher was opened.

- Make [onecopy] work everywhere, not just in the Extras menu. I
would love this feature. If [onecopy] is in a patcher, you wouldn’t
be able to open it twice, it would just bring the already opened
patcher to the foreground.

I feel you on the frustration, though. I think I have uttered the
exact same “Aargh,” but with a few more expletives tacked on.

Vlad

Vlad Spears
Urbi et orbi
http://www.daevlmakr.com

http://www.2secondfuse.com

#88955
Nov 24, 2006 at 4:53am

Hi,

> – Make [onecopy] work everywhere, not just in the Extras menu. I
> would love this feature. If [onecopy] is in a patcher, you
> wouldn’t be able to open it twice, it would just bring the already
> opened patcher to the foreground.

I highly second this feature request!!
Philippe.

#88956
Nov 24, 2006 at 6:09am

funny, this exact thing happened to me while performing in Paris this
month…my patch was acting very strange during sound check and it
took longer than it should have to discover that I accidentally
launched two copies of it (a classic DOH! moment)…once I closed
maxmsp and relaunched the one patch the patch behaved normally again…

*but I also agree that it would be nice to put [onecopy] in a patch
and just bring it to the front if accidentally opened again…

On Nov 23, 2006, at 8:53 PM, Philippe OLLIVIER wrote:

> Hi,
>
>> – Make [onecopy] work everywhere, not just in the Extras menu. I
>> would love this feature. If [onecopy] is in a patcher, you
>> wouldn’t be able to open it twice, it would just bring the already
>> opened patcher to the foreground.
>
> I highly second this feature request!!
> Philippe.

#88957
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
means you have to put a copy of lp.argus in every patch you want to
have opened only once, and due to the way Max organizes the
instantiation of objects when opening a patcher on Mac OS, the
duplicate window flashes once before the object can kick in (bringing
the original window to the front and closing the duplicate).
Ironically, on Windows, where duplicate windows are less strongly
deperecated, the cosmetic annoyance doesn’t occur.

At least you get more standard window behavior.

Argus will be in the next Starter Pack. Litter Pros are, however,
already enjoying it (some probably without even noticing its presence!)

> Aided, because I was able to open a second instance of a patcher
> and copy a portion I had deleted and moved well on from. It was
> easier than the save-as dance, by far.

In this sort of situation I would drop to the Finder, duplicate the
original and open *that* rather than have duplicate windows on the
same document. Prevents you from unwittingly overwriting all those
important changes and screaming Aaaaaaarghhhhhhhhhh.

> More importantly, I’ve also used this to open up multiple instances
> of the same patcher to create musical systems…. it’s fun.

I would also just as soon duplicate the document for this. Or
instantiate multiple copies of an abstraction. All the fun without
the pain.

————– http://www.bek.no/~pcastine/Litter/ ————-
Peter Castine +–> Litter Power & Litter Bundle for Jitter
Universal Binaries on the way
iCE: Sequencing, Recording &
Interface Building for |home | chez nous|
Max/MSP Extremely cool |bei uns | i nostri|
http://www.dspaudio.com/ http://www.castine.de

#88958
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
> > and copy a portion I had deleted and moved well on from. It was
> > easier than the save-as dance, by far.
>
> In this sort of situation I would drop to the Finder, duplicate the
> original and open *that* rather than have duplicate windows on the
> same document. Prevents you from unwittingly overwriting all those
> important changes and screaming Aaaaaaarghhhhhhhhhh.

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.

- Mattijs

#88959
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.
>
> Actually I’ve done this with a new Litter Power object. It still
> means you have to put a copy of lp.argus in every patch you want to
> have opened only once, and due to the way Max organizes the
> instantiation of objects when opening a patcher on Mac OS, the
> duplicate window flashes once before the object can kick in
> (bringing the original window to the front and closing the
> duplicate). Ironically, on Windows, where duplicate windows are
> less strongly deperecated, the cosmetic annoyance doesn’t occur.
>
> At least you get more standard window behavior.
>
> Argus will be in the next Starter Pack. Litter Pros are, however,
> already enjoying it (some probably without even noticing its
> presence!)

Ha! I am a Litter Pro! Serves me right for waiting until it’s out
of beta before using the new version.

Thanks, Peter.

Vlad

Vlad Spears
Urbi et orbi
http://www.daevlmakr.com

http://www.2secondfuse.com

#88960
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-
> world. The standard is that you duplicate your file if you want to
> open it twice. I believe Max should abide by this standard.

A preference toggle for this behavior would make everyone happy…
single-instantiation of patchers could even be the default, so people
who want the existing behavior would have to purposely turn it back on.

Vlad

Vlad Spears
Urbi et orbi
http://www.daevlmakr.com

http://www.2secondfuse.com

#88961
Nov 24, 2006 at 11:49am

Vlad Spears wrote:
> – A preference setting to toggle the behavior.

That can’t hurt, in my case it would be always keeping the existing
feature. I think that is actually not so important, might to lead to
more confusion than it aides preventing accidents.

> – A warning when about to save a patcher over a file whose contents have
> changed since the to-be-saved patcher was opened.

This should be a must, it could only ask if a newer version hasn’t been
saved, or at least point to the time of the modification it was changed.

Another approach could be to automatically undirty all other open
patchers if one is saved by hand, if none is saved by hand, deliver a
list to choose one (and only one) to save…

Maybe the easiest would be to put up a common “shall I overwrite this
file, there are other versions open as well!!!” but only if there is
more than one copy open. This would be most compliant to known
behaviours and keep the ease of use we have at the moment.

> – Make [onecopy] work everywhere, not just in the Extras menu. I would
> love this feature. If [onecopy] is in a patcher, you wouldn’t be able
> to open it twice, it would just bring the already opened patcher to the
> foreground.

That is a very logical, obvious and clear request, I can’t express how
strong I would support this.
It seemed odd to me in general, that the patches of the extras menu
behave different than other patches. I’d vote for no difference. (I want
to be able to select an extra’s patch from the windows menu for
example). I don’t know of any advantage of the existing difference…

It would make Max more consistent.

A global onecopy would also safely prevent very big performance patches
to be loaded twice, an experience probably every Maxer (not only Kim)
has had in the past…
(It would not help with the original problem posted, as you would have
to actively place a onecopy into patchers. Experience (Murphy) teaches
us, that it will be forgotton only for the important ones… ;-)

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

#88962
Nov 26, 2006 at 4:55pm

Mattijs Kneppers wrote:
> 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.

Then Max doesn’t need to be changed (I want to be able to open several
instances of the same patch as a feature), its the user who hase to
abide that standard…

And beside that, backup, backup, backup…
(a tip from someone who lost a lot and still doesn’t do it… ;-)

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

#88963
Nov 26, 2006 at 7:25pm

At 5:55 PM +0100 11/26/06, Stefan Tiedje wrote:
>Mattijs Kneppers wrote:
>>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.
>
>Then Max doesn’t need to be changed (I want to be able to open several instances of the same patch as a feature), its the user who hase to abide that standard…

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:
When you select “Open Original PatcherName”, if the patcher is already open for editing, that window is brought to the front, and no new edit instance created. If the patcher in question is not already open, it gets opened as usual.

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

-C


Chris Muir | “There are many futures and only one status quo.
cbm@well.com | This is why conservatives mostly agree,
http://www.xfade.com | and radicals always argue.” – Brian Eno

#88964
Nov 26, 2006 at 7:43pm

Any sysadmin worth his or her salt will tell you the majority of the
times a user wishes they had a backup is when they themselves have
deleted something. Disk error or hardware failure accounts for a VERY
VERY small fraction of data loss.

Sorry for the OT post.

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.

I do like the ‘bring one version to the front and edit only one
instance’ rather than a few solution.

v a d e //

http://www.vade.info
abstrakt.vade.info

On Nov 26, 2006, at 2:25 PM, Chris Muir wrote:

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

#88965
Nov 26, 2006 at 8:42pm

On 26 Nov 2006, at 19:25, Chris Muir wrote:

>
> 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.
>
Whenever I am working on a project I simply Save as…. a new version
whenever I have made significant changes – when I am working
intensively this can mean several new versions per day. My usual
practice is to append a date to the filename (in yymmdd format, so
the files are all in date order) and add a letter for the saves that
day (‘a’ for the first save, etc [I haven't run out of letters yet]).
A typical filename might look like “Fred_061129g”. Then I have a
history of the development of the patch – very useful if I decide to
refer back to an earlier version for any reason.

All of which brings up my pet beef with MacOS. I am often working on
more than one project over a period. Naturally all my files for
project Mabel are in a folder called Mabel, and all my files for
project Fred are in a folder called Fred. Yesterday I was working on
Mabel and saving updates to folder Mabel. Today I open the last
version of Fred, make some changes, and save a new version. Naturally
I expect that when I save a new version of a file it will default to
saving it where the original came from. But no, it saves it in Mabel,
because that was the last place I saved something. No matter how many
times it happens I keep on falling into this trap, which isn’t
serious, but highly annoying – I consider it to be a bug! Oh how I
wish there was a way to get rid of it! I’ve never found one, despite
hunting in help files, etc.

Best

L

Lawrence Casserley – lawrence@lcasserley.co.uk
Lawrence Electronic Operations – http://www.lcasserley.co.uk
Colourscape Music Festivals – http://www.colourscape.org.uk

#88966
Nov 26, 2006 at 8:46pm

At 2:43 PM -0500 11/26/06, vade wrote:
>Any sysadmin worth his or her salt will tell you the majority of the times a user wishes they had a backup is when they themselves have deleted something. Disk error or hardware failure accounts for a VERY VERY small fraction of data loss.

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.

-C


Chris Muir | “There are many futures and only one status quo.
cbm@well.com | This is why conservatives mostly agree,
http://www.xfade.com | and radicals always argue.” – Brian Eno

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

FWIW, with Apple’s Time Machine in Leopard, and similar built-in
backup features in Vista, these sorts of features are being
incorporated into the OS, rendering user error and application
behavior w/r/t versioning and backup moot.

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.

-Joshua

#88968
Nov 27, 2006 at 1:54am

At 2:12 PM -0800 11/26/06, Joshua Kit Clayton wrote:
>FWIW, with Apple’s Time Machine in Leopard, and similar built-in backup features in Vista, these sorts of features are being incorporated into the OS, rendering user error and application behavior w/r/t versioning and backup moot.

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.

-C


Chris Muir | “There are many futures and only one status quo.
cbm@well.com | This is why conservatives mostly agree,
http://www.xfade.com | and radicals always argue.” – Brian Eno

#88969
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
been logging my Max patchers into a CVS server for some years.) This
kind of thing is essential when you have multiple developers (which I
guess doesn’t happen very often in the Max world, since the topic
doesn’t seem to get much mention – are we all solitary laptop hackers?).

> 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
having a patcher open changes the behaviour of the application;
running two patchers is different to running one patcher, and there
are obvious cases where it’s useful to do so.

In other words, the current functionality, while nonstandard and
error-prone, is providing a kind of ad-hoc polyphony…

> I would bet many more people would be served by a “only one copy
> for editing” approach

That makes sense to me, but it’s still different to the standard
document-opening paradigm. Certainly, the current multiple-copies-
being-edited behaviour is a bit daft.

– N.

nick rothwell — composition, systems, performance — http://
http://www.cassiel.com

#88970
Nov 27, 2006 at 7:00pm

I concur.

b

#88971
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…

#88972
Nov 27, 2006 at 10:29pm

Peter Castine’s Litter object lp.argus does the trick! :)
check it out

On Nov 27, 2006, at 1:56 PM, Dan wrote:

>
> Another vote for only allowing one copy at a time to be opened for
> editing. I’ve lost work this way myself…

#88973
Nov 28, 2006 at 10:45pm

Chris Muir wrote:
> 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.

Not for editing, but for using. As Max doesn’t make a distinction
between an unlocked and a locked patch, it could happen that you unlock
two patches and edit both. This would even be usefull in editing mode,
imagine you have two modifications of the same patch you want to compare
in parallel…

> The way I would like to see this behavior changed is that: When you
> select “Open Original PatcherName”, if the patcher is already open
> for editing, that window is brought to the front, and no new edit
> instance created. If the patcher in question is not already open, it
> gets opened as usual.

As preference I would welcome it, I would never activate it though…
I’d prefer a warning…

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

But that user error will overwrite an existing patch, you might find the
old version in your backup.

Backups help in 999% against user errors, broken or stolen hard drives
are the exception… (though it does happen…)


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

#88974

You must be logged in to reply to this topic.