My engine, volume 2: molecular level
I thought I'd discuss a couple more details about my system that I
couldn't address in detail in my previous, more overview post.
Those not interested right now in putting some kind of system in place for their music will probably find nothing of value in here (and perhaps dismiss the whole thing as something in the nearby of OCD land, I'm afraid). But for those who feel it's time to add some "bone" to their "muscle", I think these additional details can perhaps inspire you and shave valuable hours off your learning curve.
A few cautions, though, before starting.
1) My system is a dynamic entity, changing as I write. This is not about putting a machine in place and then sitting on your fat butt and "let the cash roll in"; every experience, every situation you encounter as you use your system will teach you something, and it will serve you well if you get in the habit of incorporating the new lessons back into the process. Otherwise, your system will not resist the everyday assault by amorphous reality, it will degenerate and die, and you'll be back to square one having wasted a lot of time.
On the other hand, if you stick to your processes and reinforce them periodically, as you face and solve problems, at some point you'll get to a new level where you will find... Surprise! More problems! But at least they are new problems, more refined problems, different problems; because I cannot tell you how many times I've had to face one repeated same problem until I finally learned how to standardize things right (example that pops in my mind: playing sampled instruments. Occasionally, for a section in a song, I may require a convincing flute or harmonica sound, which I get by finding a nice audio sample and then playing it through the keyboard; as this occurrence is not as frequent as recording vocals or guitars, what used to happen is that I forgot how to do things from one time to the next. Drunk from my success in the moment ("I made it! There's a flute in my song!"), I moved on to the next hot issue without leaving a few considerate notes to my future self on how to replicate the results. And I cannot tell you how humiliating is having to DuckDuckGo again from scratch something that you know you already nailed a year ago...)
2) No copycats possible. I provide my system for "multipurpose inspiration", inspiration which can range from a simple "Hey, having a system is good", to "I like the format he uses to visualize x", or maybe "I'll adopt it as-is and see in which ways it crashes and burns for me". Take only what resonates with you, I invite you to pillage, mutilate, colonize, invade and contaminate (also to foster, develop, sponsor, protect...) whatever you feel like at your leisure, all conditioned to your musical needs, priorities and goals.
3) As an additional disclaimer, for good and for bad, I've been know to be a "statistically remarkable" person, something that often manifests in the fact that I find very easy to do some things that others find hard, but the other way round is also true. So some things in here can perhaps sound very corny, and others perhaps too profound, I never know which one is which so here comes the whole lot... :)
And so, with all the notes of caution out of the way, here is the part of my process I want to focus on today (red grid in the image):
In my previous post I said, for the sake of simplification, that each of the blue rectangles at the top has "an instruction list associated". Such simplification can lead to a bit of a rabbit hole, so I thought I'd better elaborate a little.
Extensive processes, full of options and moving parts, like tracking, editing or adding fx are, are too complex to be crammed into a single instruction list (even the slim and time tested TWI Job Breakdown that I mentioned in my last post - Here is the template I adapted). You would end up having a list with too many steps, very difficult to navigate and manage.
I've found it works better to keep those lists' length at around 1-3 pages, and you manage those lists, that now are many, by creating an intermediate layer. So, in fact, each of the blue rectangles doesn't have a list, but a whole FOLDER full of lists associated.
And the content of that folder, this is the key to the kingdom, is standardized; it sticks to one fixed structure in all cases. Here is the structure I am using as of now for those folders (from now on, I'll refer to the blue rectangles as "Stages" and to the individual lists as "processes"):
The file DIAGRAM is actually named in caps, because that makes it easy to differentiate at a glance. It is the first thing that my eye looks for when I enter any folder.
This file is intended to give me a quick overview of what goes on in the defined stage. In most of the cases, I use for it a simple spreadsheet document with a few lines, showing in which order the process lists must be run. But depending on the needs of the task, a simple txt file can suffice, while in others more complexity (pictures, a few quick notes, sometimes a small decision tree...) can be useful too. Also, I sometimes write little notes on the diagram when I finish a session; anything that can help my brain "rewire" quickly when the time comes. No matter what I use, the purpose that must be served is that the document has to provide, at one glance, an overview, a "map" of where to find things. And any change in this document is done sticking as much as possible to the "don't make me think" principle; I can get as complex as I need later, at process level, in the different job breakdown lists.
That's how standardization works; by "anchoring" something, it liberates your brain for other decisions. That's why all cars have the gear shift in the same location; if each car chose a different place, it would be yet another thing to have in account. Abusing the simile, this Diagram file is a bit like my "gear shift". I know automatically where to find it and it puts me in control.
I tried other options before I settled with this system; for example, for a time, instead of establishing the order of processes through the diagram, I tried just numbering the files and let just the list in the file manager serve as the "Diagram"... But I found that this was a bit high maintenance, and caused me resistance to change things.
Here's an example from just the other day: inside the editing stage, I have a process called "volume homogenization" (especially required in vocals, which always have a huge dynamic range per se, let alone when the track has been "patched" from a lot of different takes), and also another process called "cleaning the take" (removing buzzes, accidental noises, breathes and gasps...) At first, it seemed a good idea to put "cleaning the take" BEFORE "volume homogenization". But when I actually ran the whole series, I discovered very quickly that it is better to do the cleaning AFTER the volume has been homogenized, as only when the volume is homogeneous you can make sensible decisions about which noises to take out, how much is too little or too dry...
With my current system, all that was required to make the change was swapping the order of two lines in the diagram. With numbered processes I would have had to change file names, maybe the content of the documents too... (Plus you were never sure if the contents of the folders were up to date and therefore you could trust the order... Plus when I had to put some new process in between two existing, I soon found it was better to name the files 10,20,30 instead of 1,2,3... So there you go some rework, plus this way of naming always felt messy, etc...)
Another point that I've found is key to make this system work is keeping a very tight name consistency among the different levels; If a process in the diagram is called "Comping track", the corresponding process list must exactly be called "comping track"; not "comping", "track comped" or some other fancy thing. I tended to slack on this point because it sounds so silly and it's a drag to stop what you're doing to close a file you're using, renaming it, reopening, finding where you were... but this consistency pays off quickly, as it reduces your mental overhead, and makes the system way more robust.
As with all standards, this structure is only sort of a "starting point", intended to provide a guideline, not to be followed blindly. In my case, it is turning out to work as a "bare minimum"; in any of my folders, I'm always going to find this "Diagram+process lists" structure (if I don't find it I'll create it right away). But in addition to that, I can always put more stuff in the folders, stuff that is particular to each task; cheatsheets, handy files or links... anything that can make things easier and quicker next time. Also, lately, I sometimes write to myself a "README" file too, usually if I left in the middle of a process, or when I meet an obstacle that "lives" between two processes... If I enter the folder and see the "README", it is it the one that I open; it takes prevalence over the Diagram. Once solved the issues, I delete the readme and go back to the Diagram, but I don't know how this readme could evolve in the future.
At the moment, I'm happy with this mixture of "the structure" plus "other things needed" living in the same folder, but if at some point things became difficult to find, I guess I would create a new subfolder for those "other things needed", and include that subfolder within the standard, etc...
You will appreciate that what this system intends (perhaps is what all systems do) is creating a balance between free flow (out of which creativity comes, but which can degenerate in chaos), and structure (needed so that you don't do silly things and waste effort... but always at the risk of becoming stifling).
This all may sound pretty convoluted, but in the end the final result is that I turn on the computer and, boom, in 8 seconds I know what the current state of all my music is, and boom, in 5 seconds I'm advancing in one of my songs, and when I get saturated with it, boom, in 5 seconds I'm working on the next one...
And this happens invariably either if I had sleep last night or not, if the week so far has been stressing or calmed, if I've been feeling energetic the whole day or a neck pain is bugging me... Of course the outcome will be bigger or smaller depending on those circumstances, but every day there's some advance, and it is always consistent, even if the order of magnitude some days is 5 and others 0.2.
This new way of functioning sometimes makes me feel like a farmer ploughing his furrow, and what a joy it is to see all the fruits as they grow a little every day... :)
As always, I hope that among these ideas you find something you can take to your own turf; at the very least, the notion of a system, and the huge benefits you can get out of it.
"I must create a system or be enslaved by another man's" - William Blake.
Those not interested right now in putting some kind of system in place for their music will probably find nothing of value in here (and perhaps dismiss the whole thing as something in the nearby of OCD land, I'm afraid). But for those who feel it's time to add some "bone" to their "muscle", I think these additional details can perhaps inspire you and shave valuable hours off your learning curve.
A few cautions, though, before starting.
1) My system is a dynamic entity, changing as I write. This is not about putting a machine in place and then sitting on your fat butt and "let the cash roll in"; every experience, every situation you encounter as you use your system will teach you something, and it will serve you well if you get in the habit of incorporating the new lessons back into the process. Otherwise, your system will not resist the everyday assault by amorphous reality, it will degenerate and die, and you'll be back to square one having wasted a lot of time.
On the other hand, if you stick to your processes and reinforce them periodically, as you face and solve problems, at some point you'll get to a new level where you will find... Surprise! More problems! But at least they are new problems, more refined problems, different problems; because I cannot tell you how many times I've had to face one repeated same problem until I finally learned how to standardize things right (example that pops in my mind: playing sampled instruments. Occasionally, for a section in a song, I may require a convincing flute or harmonica sound, which I get by finding a nice audio sample and then playing it through the keyboard; as this occurrence is not as frequent as recording vocals or guitars, what used to happen is that I forgot how to do things from one time to the next. Drunk from my success in the moment ("I made it! There's a flute in my song!"), I moved on to the next hot issue without leaving a few considerate notes to my future self on how to replicate the results. And I cannot tell you how humiliating is having to DuckDuckGo again from scratch something that you know you already nailed a year ago...)
2) No copycats possible. I provide my system for "multipurpose inspiration", inspiration which can range from a simple "Hey, having a system is good", to "I like the format he uses to visualize x", or maybe "I'll adopt it as-is and see in which ways it crashes and burns for me". Take only what resonates with you, I invite you to pillage, mutilate, colonize, invade and contaminate (also to foster, develop, sponsor, protect...) whatever you feel like at your leisure, all conditioned to your musical needs, priorities and goals.
3) As an additional disclaimer, for good and for bad, I've been know to be a "statistically remarkable" person, something that often manifests in the fact that I find very easy to do some things that others find hard, but the other way round is also true. So some things in here can perhaps sound very corny, and others perhaps too profound, I never know which one is which so here comes the whole lot... :)
And so, with all the notes of caution out of the way, here is the part of my process I want to focus on today (red grid in the image):
In my previous post I said, for the sake of simplification, that each of the blue rectangles at the top has "an instruction list associated". Such simplification can lead to a bit of a rabbit hole, so I thought I'd better elaborate a little.
Extensive processes, full of options and moving parts, like tracking, editing or adding fx are, are too complex to be crammed into a single instruction list (even the slim and time tested TWI Job Breakdown that I mentioned in my last post - Here is the template I adapted). You would end up having a list with too many steps, very difficult to navigate and manage.
I've found it works better to keep those lists' length at around 1-3 pages, and you manage those lists, that now are many, by creating an intermediate layer. So, in fact, each of the blue rectangles doesn't have a list, but a whole FOLDER full of lists associated.
And the content of that folder, this is the key to the kingdom, is standardized; it sticks to one fixed structure in all cases. Here is the structure I am using as of now for those folders (from now on, I'll refer to the blue rectangles as "Stages" and to the individual lists as "processes"):
The file DIAGRAM is actually named in caps, because that makes it easy to differentiate at a glance. It is the first thing that my eye looks for when I enter any folder.
This file is intended to give me a quick overview of what goes on in the defined stage. In most of the cases, I use for it a simple spreadsheet document with a few lines, showing in which order the process lists must be run. But depending on the needs of the task, a simple txt file can suffice, while in others more complexity (pictures, a few quick notes, sometimes a small decision tree...) can be useful too. Also, I sometimes write little notes on the diagram when I finish a session; anything that can help my brain "rewire" quickly when the time comes. No matter what I use, the purpose that must be served is that the document has to provide, at one glance, an overview, a "map" of where to find things. And any change in this document is done sticking as much as possible to the "don't make me think" principle; I can get as complex as I need later, at process level, in the different job breakdown lists.
That's how standardization works; by "anchoring" something, it liberates your brain for other decisions. That's why all cars have the gear shift in the same location; if each car chose a different place, it would be yet another thing to have in account. Abusing the simile, this Diagram file is a bit like my "gear shift". I know automatically where to find it and it puts me in control.
I tried other options before I settled with this system; for example, for a time, instead of establishing the order of processes through the diagram, I tried just numbering the files and let just the list in the file manager serve as the "Diagram"... But I found that this was a bit high maintenance, and caused me resistance to change things.
Here's an example from just the other day: inside the editing stage, I have a process called "volume homogenization" (especially required in vocals, which always have a huge dynamic range per se, let alone when the track has been "patched" from a lot of different takes), and also another process called "cleaning the take" (removing buzzes, accidental noises, breathes and gasps...) At first, it seemed a good idea to put "cleaning the take" BEFORE "volume homogenization". But when I actually ran the whole series, I discovered very quickly that it is better to do the cleaning AFTER the volume has been homogenized, as only when the volume is homogeneous you can make sensible decisions about which noises to take out, how much is too little or too dry...
With my current system, all that was required to make the change was swapping the order of two lines in the diagram. With numbered processes I would have had to change file names, maybe the content of the documents too... (Plus you were never sure if the contents of the folders were up to date and therefore you could trust the order... Plus when I had to put some new process in between two existing, I soon found it was better to name the files 10,20,30 instead of 1,2,3... So there you go some rework, plus this way of naming always felt messy, etc...)
Another point that I've found is key to make this system work is keeping a very tight name consistency among the different levels; If a process in the diagram is called "Comping track", the corresponding process list must exactly be called "comping track"; not "comping", "track comped" or some other fancy thing. I tended to slack on this point because it sounds so silly and it's a drag to stop what you're doing to close a file you're using, renaming it, reopening, finding where you were... but this consistency pays off quickly, as it reduces your mental overhead, and makes the system way more robust.
As with all standards, this structure is only sort of a "starting point", intended to provide a guideline, not to be followed blindly. In my case, it is turning out to work as a "bare minimum"; in any of my folders, I'm always going to find this "Diagram+process lists" structure (if I don't find it I'll create it right away). But in addition to that, I can always put more stuff in the folders, stuff that is particular to each task; cheatsheets, handy files or links... anything that can make things easier and quicker next time. Also, lately, I sometimes write to myself a "README" file too, usually if I left in the middle of a process, or when I meet an obstacle that "lives" between two processes... If I enter the folder and see the "README", it is it the one that I open; it takes prevalence over the Diagram. Once solved the issues, I delete the readme and go back to the Diagram, but I don't know how this readme could evolve in the future.
At the moment, I'm happy with this mixture of "the structure" plus "other things needed" living in the same folder, but if at some point things became difficult to find, I guess I would create a new subfolder for those "other things needed", and include that subfolder within the standard, etc...
You will appreciate that what this system intends (perhaps is what all systems do) is creating a balance between free flow (out of which creativity comes, but which can degenerate in chaos), and structure (needed so that you don't do silly things and waste effort... but always at the risk of becoming stifling).
This all may sound pretty convoluted, but in the end the final result is that I turn on the computer and, boom, in 8 seconds I know what the current state of all my music is, and boom, in 5 seconds I'm advancing in one of my songs, and when I get saturated with it, boom, in 5 seconds I'm working on the next one...
And this happens invariably either if I had sleep last night or not, if the week so far has been stressing or calmed, if I've been feeling energetic the whole day or a neck pain is bugging me... Of course the outcome will be bigger or smaller depending on those circumstances, but every day there's some advance, and it is always consistent, even if the order of magnitude some days is 5 and others 0.2.
This new way of functioning sometimes makes me feel like a farmer ploughing his furrow, and what a joy it is to see all the fruits as they grow a little every day... :)
As always, I hope that among these ideas you find something you can take to your own turf; at the very least, the notion of a system, and the huge benefits you can get out of it.
"I must create a system or be enslaved by another man's" - William Blake.
