[ot] organizational strategies
I was fruitlessly searching for a missing patch and
realized my files are a mess. Does anyone have any
organizational or workflow advice you would like to
share? I have seen some successful max minds using
their computers and it seems like most have organized
systems for managing their data, though I couldn’t
tell how exactly they worked. I have also seen a patch
by Richard Dudas that scared me.
after a few million files have been going over my
desktop in various contexts i find that there is only
one organization system which really works:
always give files useful names, and sort everything once
a day into monthly subfolders.
i have a monthly "email" folder, a monthly "downloads"
folder, a monthly "office and webdesign" folder, one
for safety backups, one for nuendo projects, one for
skribbles, and of course one for maxmsp programming
inside my maxmsp search path.
if you know anything about that cool idea you had, then
it is that is was about 5 months back.
i have been switching to my monthly onscreen life organisation
scheme because that no longer requires that i have to sort
things from 2 years back.
Not particularly Max-related, but I have started using DevonThink Pro
and find it quite useful for organizing my computer life:
Now I can keep all files related to a project together (including
links to Max-patches). You may or may not like the database approach
it is based on, though.
Some simple things that will help alot:
CONSISTENT, LOGICAL FILENAMING CONVENTIONS
1. Consistent file-naming conventions. e.g., GOOD — audio_router.mxt;
audio_switcher.mxt; audio_gain.mxt. BAD — gain_for_audio.mxt;
If you have files related to specific projects and you know you won’t reuse
them in other projects, keep names consistent. e.g., GOOD –
MySong_thing.mxt; MySong_otherthing.mxt; MySong_lasthing.mxt. BAD –
thing_for_mysong.mxt; other_mysong_thing.mxt; song_my_lasthing.mxt
2. Consistent directory-naming conventions. Following above logic, but need
to decide if organize by project, by functionality (a folder for audio
objects, one for jitter objects, one for midi objects, etc.), or a hybrid.
Whatever. Just be consistent.
3. I wouldn’t put version info in the patch title. If you’re using
ThePatchV01.mxt in a bunch of places, then modify your patch and name it
ThePatch02.mxt, you’ll have to change the refernce all over. I’d put
versioning info inside the patch.
4. If you *do* put versioning info in the name, beware proper sorting. Pad
zeros with numbers, do dates YYMMDD:
GOOD – YYMMDD
BAD – MMDDYY
1. I think it’s important to have logical inlet/outlet use across patches.
e.g., any patch accepting L/R audio uses the left two inlets for that; any
patch outputting a jitter stream does it from the rightmost outlet. Not
saying these have to be your rules, just something as consistent as
2. Make use of color coding withing patches to group functionality, either
as a universal assignment, or universal for a project, or just within a
patch. e.g., I wrote my own state-saving logic before Pattr came out. I
use blue as a universal color in all my patches to indicate elements tied to
my state saving.
Lots of other things you can do, but thats where I’d start.
On OSX, I’m using "URL Manager Pro".
Not only for web URLs, but also to bookmark my localhost files and
Just drag&drop, create folders and sub-folders, sort by name, date or
color labels, add any description, etc.
I’m using one document for my own patchers, another one for the help
patchers, one document to quickly load Max tutorials and PDF
Powerful, and cheap!