command-S should definetly save the new version into the old file, and not somewhere else. this sounds very strange and not max releated - any third party utility in your system which could cause that?

Save as... will indeed take you to the last used folder but Save should overwrite the original file. What's probably meant is saving a new patch. That being said, I don't like the Save as... behavior either.

Ok I did my homework a bit better - thank you both for the prompts. It is indeed Save As - what I tend to do is have filenames end in a version number Eg DatprocessingV2-0-3.maxpat

I work on the patch, click Save As, update the version number and forget to look at the path that is displayed (because I have 10 other ideas in my head I want to turn into a patch)

Then indeed it saves it to whatever the last folder was I saved something into.

So rephrasing my question: can the default path of a 'Save As..' be changed to be the path the current patcher is in, rather than whichever folder I last saved to?

The problem is actually that I have built quite a big library of patches and abstractions, so the path I am looking for is often quite a few clicks away

no, not even with third party extensions to the OS.

"save as" means by definition "save as something else than what it has been before" and this not yet existent file simply does not have a path.

the only thing you can do is to use lesser folders. i know that it can be cool to save new versions and keep all the prior ones, but then you must live with that extra bit of work, either renaming or in the form of sorting into the right place.

let my try a little paradox intervention: it is great that you have so many subfolders for your patches, that you have lost overview where a file has to go, isnt it?

-110

Hmm well the patch knows very well where it is and what it's path is, so it seems feasible to me that the 'save as...' options starts with the path the patch was previously saved in. I guess I could even create an abstraction that reads the current path, and saves the patch in the same path but just ups the version number +1

Your paradox intervention (new concept to me) had me confused for a while... but in fact I know exactly where my patches are :-) the amount of folders is just about right, I'd just like to have a a way that for the next version of the same patch, for each patch, I don't have to browse to the folder from the same starting point.

you said the patch would know where its subpatchers are located. that does not help us, because the patch has nothing to do with the save dialog of the OS. i think even if they would meet in real life they had a communication problem, because the OS speaks mandarin and the max patch only speaks spanish.

your best bet is that there is eventually an extension to the OS available hich automatically creates copies of files overwritten, so that you could just "save" a file, and the OS makes sure that the original is copied and renamed before it is going to be overwritten.

it might also be that i am overlooking an obvious solution from inside the max patch, for example using java or javascript.

"The problem is actually that I have built quite a big library of patches and abstractions, so the path I am looking for is often quite a few clicks away"

you might laugh about this solution, but when i am in this situation i open my abstractions folder and the main folder of the current max project, plus i use the "default folder" extension for mac OS since 20 years, which makes navigation a bit easier. when yu are talking about clicks i fell i want to add thaht i mostly use the cursor keys to navigate in file browsers such as the OS´s, it seems faster.

-110

Isn't it just a matter of changing the save dialog's default behavior in code? I assume the Max devs can choose what is the behavior, point to the last used folder or the original location of a patch.

I don't get it, and I wonder if we're talking about the same thing. If I click 'Save As' the suggested name for the patch is the current name.

If the 'Save As' dialogue knows the current filename why can't it know the current file path?

As a very off topic aside:

I have not managed to navigate dialog boxes in Max OSX, I'll google it and see if I can get the hang of it. I switched to Mac 3 years ago, but in fact I still miss the dialog boxes on windows, which allow you to show the full tree hierarchy, expand and collapse branches, open explore windows in specific folders and even move and rename files within the 'save' and 'open' dialog. It may sound out of place - but it's often when you save or open a file that you realise you need to do some moving/renaming.

that is simply the logic behind "save" and "save as". "save" means into the same file, "safe as" means into a new file. because this includes the path, it is not default behavior that an application tells the finder to go to where the original was. and as soon as you save a modified file into a new one, the previous open document is now the new one.

you must not forget that this is not the normal case, that you have different subfolders for a bunch of files with unique names. this almost only happens in programming languages which _require unique names in the file path. maxmsp is an absolute exception here, at least when the user isnt making the mistake using double names. :)

for photoshop documents it can happen that there is a "sweet.jpg" in /cats as well as in /dogs. in a html project it is quite common to have dozens of "index.html", one in each folder. to which one would you like the dialog to jump when you are about to save one of them?

maxmsp could theoretically also track and store the paths of each file it opened, but it does not, because it is simply not needed in a system which does not allow double file names. looking from the patcher level, max only know the names of the externals and patches called from the root patcher, but not their path.

about navigating: most apps allow 2 modes in their open and save dialogs, compact and extended. you´d trigger the extended mode by clicking into the arrow in the path menu in case its not activated.

and you really should try stclairsoft.com/DefaultFolderX and see if you like that better.

you could make your own save system save from inside your patch using thispatcher. Also maybe savjing as e project would help you ?

I was looking for a save command - but couldn't find it. Can you help?

I was thinking of making a very simple abstraction that reads the current file's path, and automatically ups the version number with 1, and saves the patch.

I know I can read the patchers' file patch by sending a "path" message into [thispatcher] - but I don't know how to make a patch save itself - if that is possible at all!

"path" will output the path from [thispatcher] and you could change the name from "mypatch 7" to "mypatch 8" before saving again with not too much headache.

but are you sure you want to have a thispatcher object and releated stuff in every instance of every ofyour 3000 abstractions?

What do you do with the old versions? Did you ever needed them? It seem you want to have a versioning system like git. In this case you can get to older versions with that versioning system without a need to give them version names. I simply have my patches in my dropbox and of course in my time machine. Whenever I need to get to an older version I can find it there. File names with version numbers wouldn't work for subpatchers anyway. Most of my patching is in subpatchers. The main patch would only get a new name if it has changed significantly. That doesn't happen too often (maybe once in two years...;-) Maybe its time to get rid of old habits and try a different workflow. The use of projects might be a good starting point...

A developer can dictate the behavior of "Save as…", but the Apple User Interface Guidelines do specify certain behavior for apps to follow, and the user experience with this sort of thing is supposed to be consistent across all applications under Mac OS.

I think the Guidelines may actually allow certain variations in the behavior of "Save as…", but probably no "canonical" behavior will match what you want.

Not that Cycling '74 has always followed Mac OS UI Guidelines particularly closely -- sometimes Cycling would prefer to implement the same behavior on Mac and Windows, regardless of whether Mac users want the Windows behavior (or vice versa). And sometimes they've implemented behavior that follows neither Mac nor Windows conventions.

La vie, c'est dur.

Thank you all for your contributions - this is a really helpful discussion for me. I've never programmed as a profession though I think I average about 20 hours a week for the last couple of years - all on Max MSP. I'm happy to change my workflow and would welcome your recommendations. So first, why do I use versioning?

* to make sure my old programs don't break. When I add new functionality, move inlets and outlets around and change the inner working, some of my older programs will stop working. Or even the same program may stop working if I call the same abstraction elsewhere. That's the idea behind abstractions right, that you use them in many places?

* to be able to 'go back' if (one part) of the functionality stops working. This is especially for patches that do a number of things and I may not find every bug in testing: and I may not even remember how I got it working in the previous version.

I use TimeMachine but only connect my external drive about once a month: which is not often enough to be able to 'go back' to the previous version. So without using versioning, how can I change my workflow and still have those above two points covered?

Finally I do live gigs, and more than once have found out just before a gig that my newly developed system did not work well enough (or that one function I hadn't been testing just stopped working) - and reverted to a previous version which was a life saver.

@Stefan - I do use the older versions, mainly when before a gig I need to revert to a previous (fully working) version. I'm continuously adding functionality to one big live performance system, my main patch is changing too (including name)

@Peter - La vie is not that dur.. I'm thoroughly enjoying it, and a lot of it through Max :-)

I think there are several options. One is to save a working version as a collective. I only recently started with projects, but I think there are options for versioning too and it seems to be a solid concept. There are several colleagues who do use versioning systems... In general I also have an always changing system for live performance. I usually do not a "save as" but go to the finder and duplicate my old working version. (I am navigating faster in finder than in a save dialog and much faster than in the Max Browser...;-) In the end I want a the newest to be the working version, that keeps the name and all aliases in place. Only for emergency I could go back to my duplicate...

Hi BASVLK

To go back to your original problem. I have the same issue, and like you I have had it for a while and it's very annoying. When I am working on a patch and do a "save as" or just a "save" the file gets saved into the folder of the most recent patch I was working on prior to the current one. Even if I do a "save as" and specify the correct folder, it will save it into the location of the most recent patch prior to the current one, or sometime the Max folder itself. Did you ever find the cause or a solution to this issue?

Thanks Alan

Hi Alan - I gave up, frankly! Also I got the impression I was the only one who thought about it this way, so I'm happy to hear I'm not alone :-)

I'm at the moment playing more with Arduino, and just installed GitHub. I may end up using GitHub for my max patches too

OK, I guess I will struggle on.