help getting Max to follow symlinks
I'm trying to wrangle all of my Max tools in to a single git repo, but I can't seem to get Max to follow the symlinks that would make it all work.
I have a single directory "~/Documents/XM Tools" with the subdirectories "XM Templates", "XM Clippings", "XM Patches", and "XM Externals". I wrote a script that symlinks them to the appropriate folders in the installed application directory (side question, why is all of this a directory in the Applications folder and not within the ~/Library/Application Support directory?). e.g. it executes "ln -s ~/Documents/XM Tools/XM Templates/ /Applications/Max6/templates/" and similar for each directory.
Every thing works just fine until I try to use any of them in Max, which appears to not even see them. As I understand it, the File -> New From Template menu should show an entry of "XM Templates" which contains all the templates I have in ~/Documents/XM Tools/XM Templates. All it shows is the stock templates. Same for clippings, externals, and patches.
I tried adding ~/Documents/XM Tools to the "File Preferences" search path but it doesn't resolve the missing Templates and Clippings menu entries.
Is there a trick to getting Max to follow symlinks?
Still haven't figured this one out. I found a reference in the docs to aliases not being fully supported, but nothing for symlinks. How is everyone else tracking their projects? Would Really suck to have to do this all via rsync.
Anyone provide some insight on this issue? It recently pissed me off again after updating Max, realizing all my clippings and templates were lost thanks to the app "install" being a byzantine hierarchy of folders, some of which users are supposed to manage files in. Luckily I have backups, but all this dispersed micromanaging is _really_ getting on my nerves.
Max doesn't support symlinks.
Sounds Great! The 6.1 post doesn't go in to much detail on the concept, any idea if they will be git friendly?
The package and project features are very nice. There are many times, however, when I've wished for support for standard file system features to organize files (Mac OS aliases, Windows links [if that's the right term], symlinks, and the like) that are already familiar to users, rather than the invention of new tools that users have to learn from scratch.
I daresay you folks have your reasons. And it's not that I would wish to denigrate any of the work you've done (really not). But there is something to be said for a user to (for instance), be able to use aliases for organizing file references in Max AND Live AND Sibelius AND ProTools AND GarageBand AND Office AND iWork AND XCode AND…, rather than having to learn a different (and possibly idiosyncratic) technique for each and every application program he or she uses.
But I guess there are other points of view.
This is the skinny for Windows on hardlinks, junctions, symlinks:
Junctions used to be somewhat unsafe to use in older versions, due to not alerting the user to oh . . . say, wiping out the contents of an entire drive when they thought they were just deleting an alias :o Also, recursion / loops (if you had a junction leading back to the filesystem from whence you had junctioned to start with) and antivirus etc - endless scans.
But that's all tidied up now.
I absolutely share Peter's point of view in that all x-platform software could benefit greatly in UX terms by using the host OS services as far as possible.
Windows and OS X have so many analogues for basic filesystem (and the like) tasks that copy-exact behaviour could easily be designed in, and in the medium to long term I think having some decent developers versed in the semantics of the respective target platforms would pay off in spades.
It's not like it's such a burden - most of these are basic simple OS provided mechanisms. Relative paths for pitys sake. So many of the complaints and confusion I see on the forum . . . one very frustrated poster just recently, can't say as I disagreed with the general thrust of the arguments (dnk777) . . . no need for any of this.
Peter Castine communicated this frustration with more restraint than dnk777, here's my attempt.
Max is a fantastically useful programming language - but it's not a great IDE or RAD tool. It's not bad software by any stretch but the stench of Academia clings hard.
It's my hope that the M4L deal brings the revenue to fuel serious inroads on all this. I'd like to see a Max that functioned along the lines of some of the Adobe Suite apps, or take cues and ideas from any other workflow-oriented CC application.
And please go native for the application frameworks.
Pretty please? :)
I decided to install 6.1 tonight and try out the new packages system. Great feature! Certainly a step in the right direction.
However, a core problem still exists: I can not have my files where I want them. With the current implementation of packages, it appears they MUST either be in the packages directory of the main app directory (/Applications/Max 6.1/Packages), or in ~/Documents/Max/Packages. I don't use ~/Documents/Max, I use ~/Dropbox/Max. Of course, symbolic links do not work. Will Max _ever_ support this most basic filesystem feature?
Is there a setting I can adjust somewhere in the interim to make Max look elsewhere for my packages?
Dropbox works with symlinks (just tested it). So you can do this the other way around for the time being.
Obviously we are aware of this limitation. For the time being, though, it is how it is.
Best, Jeremy
I have a question - why is it that Max has to support these features at all? Should not filesystem stuff be completely transparent to applications?
I know it seems simple, but it's actually more complicated than you might think based on the way Max handles file types while searching. Particularly on Windows, where .lnk files are not the equivalent of symbolic links on OSX (Junctions offer equivalent functionality on Windows, though -- although depending on your Windows version, Junctions may wreak havoc when deleted). So platform parity is also a concern here.
I feel your pain -- as I said, it's a known limitation which we're not oblivious to, but it's also not entirely a matter of flipping a switch.
Best, Jeremy
Hi Jeremy, thanks for taking the time to answer.
I think the solution to the breakage caused by older versions of Windows not providing sufficient warning or failsafe mechanisms for the user when deleting junctions is . . . drop support for those Windows versions.
I think I can safely speak for Microsoft (though I am not speaking for Microsoft) . . . you'd be doing the world a favour generally, and I say this as somewhat of a Windows advocate.
Also . . . and I may be slightly out of line here - is it really C74's responsibility for end-users not being competent on their chosen platform? Did you guys stop placing files in directories because OS X (previously) gave the user no warning that the file-replace semantics of Finder would nuke the existing contents of a directory rather than merge the contents as on Windows?
[edit]
I'm not sure symlinks == junctions, though they provide similar functionality. A symlink is basically a reference-counter for a resource like a file or whatnot - whereas a junction is specifically a redirect on a directory no? I really ought to brush up on this stuff! :)
Haha. We have a lot of respect for our users' abilities both on and off of the computer. But in general, we want to avoid relying on or advocating solutions which present the opportunity for catastrophic data loss. :-) Anyway, that was just an offhand observation. It's not point #1 on the list of obstacles to this working.
BTW, you may be right about junctions -- I may need to do some brush-up on the available Windows alternatives and their particular qualities, as well.
We'll keep you posted if anything changes with regard to this stuff.
Best, Jeremy
Thanks, hoss.