Details
In this episode, we look at principles of redundancy and organization when working on a project.
Comment
Details
In this episode, we look at principles of redundancy and organization when working on a project.
Comment
In this episode, we look at principles of redundancy and organization when working on a project.
Listen to Episode 09: Organization and Redundancy by Carl Irwin MP3 song. Episode 09: Organization and Redundancy song from Carl Irwin is available on Audio.com. The duration of song is 27:34. This high-quality MP3 track has 1411.2 kbps bitrate and was uploaded on 18 Apr 2024. Stream and download Episode 09: Organization and Redundancy by Carl Irwin for free on Audio.com – your ultimate destination for MP3 music.
Comment
Loading comments...
The podcast episode discusses the importance of organization and redundancy for film score composers. It emphasizes the need for having backup systems and software to prevent loss of work in case of system failures. The speaker advises against upgrading operating systems or software in the middle of a project and recommends using long-term service releases for stability. Additionally, the speaker suggests waiting for the first patch release before updating software and using default configurations to avoid compatibility issues. The speaker also shares a personal story about the importance of file redundancy and the consequences of not having backups. Hello, I'm Karl Irwin, and this is Spotting Cubes, a podcast for the amateur and hobbyist film score composer. Today we're going to be talking about something really, really important. I don't think this will be a terribly long episode, but this is a vital one. We're going to talk about organization and redundance. Let's first talk about redundance. I think that's probably the umbrella issue here, even before we get to the topic of organization. Redundance, having more than one version of something, whatever it is that you're working on. First, let's talk about redundancy of system. Some of what I'm going to say here is a bit of a luxury. If you're an amateur hobbyist composer of any kind, film music or not, you may only have one system, and, of course, that's fine. You work with what you have, particularly as a hobbyist. If you're a professional, you're going to be dealing with redundance. What this could mean is you might have a desktop, but then also have a laptop, and they don't necessarily have to be matched in terms of their specs. What we're talking about is having at least two systems with the same or similar core architecture and software, and particularly dealing with the major programs and libraries that you're using, so the more significant elements that you're using. The reason for this is quite obvious. If you have some kind of catastrophic failure on the system you're using, you have something that you can jump over to to continue the work, and you should be able to do that with very little intervention in terms of uploading or installing additional software. You want to have kind of the core stuff in place, and, for me, we're going to talk about software a little bit, but, for me, I have found that I really limit on purpose. I limit the software that I use to a very streamlined kind of structure. I don't get terribly complicated. More on that in a moment. A couple of never and always kind of policies here, right? So, the first one is never, never upgrade in the middle of a project. Never upgrade in the middle of a project. So, at a system level, never, apart from kind of standard operating system security patches, you know, those normal kinds of updates that come along, never update the operating system to a new version in the middle of a project. Always avoid that. Never do it. Never update your software that you're using to a new version in the middle of a project. Always put that off until you have a window in between projects where you can do your upgrade and not have it cause problems, because you can upgrade, and you find that features will change. When you're upgrading an operating system, you may find that it may not play nice with the software that you're using. So, always hold off upgrading either your operating system, the main structure on which you're working, and the main software that you're using until you have a window between projects. Never do it in the middle. Always, always, this is just a recommendation, but I recommend always use long-term service releases for your operating system or your software. So what is that? What is a long-term service release? So I'm a Linux user. I actually use a Linux platform, Linux operating system, and I use Linux software, native Linux software, and also native libraries, and I use what's called the long-term service releases. So because Linux has frequent updates, I could change my operating system twice a year. I don't do that. What they do is they put out what's called a long-term service release, and that release is supposed to get support from the developers for at least two to three years, and I always anchor on the long-term service releases. I do not upgrade to the annual or biannual releases. I always stick with the long-term service ones because those get the most support and the longest support, and by the time you're at the end of life and end of support, they're usually quite stable, and they get the most focus. So stick to those. Now software works the same way. A lot of software will have long-term service releases, and then they'll have kind of releases in between those major releases. You want to focus on those. You want to focus on the stable ones that have the longest amount of support. I recommend that. That is just a piece of advice. Only update – this is another – this is kind of another tier to that. Only update after the first patch release on your software or your operating system. So what this could mean is let's pretend that the software we're using is called Music Software. Music Software 5. It doesn't matter if it's a digital audio workstation, notation software, an audio editor, any other kind of audio service or an operating system. It's Music Software 5. That's the software we're dealing with. I say that you wait until Music Software 5.1. It's not usually until you get to the first patch release that you get really good stability. So that's something to consider. Be patient. This is kind of like buying a car. Especially if you're patient. If you go into buying a car – and I don't mean to give advice on buying a car or a house or something like that, something big-ticket item. If you go into the process patiently and with a willingness to compromise on what you ultimately end up with, you will end up with the best deal. You won't end up with the best deal that day that may require that you go in, you shop around, and you go home, and you wait a week or a month, and then the deal opens up. But you need to be patient. So it goes with software. Whenever you're upgrading, be patient with the upgrades. Do not just go after the new and shiny thing. New and shiny is only new and shiny. I can guarantee that any time an upgrade looks new and shiny, the one thing I can guarantee about it is that it is new and shiny. It doesn't necessarily mean that it works right. It doesn't necessarily mean that it will be compatible with what you're doing. It doesn't necessarily mean that it won't completely upend whatever workflow you've created. So keep that in mind. Be patient, wait until major releases, and wait until the first patch release, and only do it in a window, okay, in between your projects. So this is kind of the conservative view of this, and I highly recommend that. Even as an amateur and hobbyist, you don't want to be crashing your entire effort in the middle of a project, and then having to find some way to get back to where you were. That can be a major headache and almost undoable. So just to recap, system, have at least two systems, if you can, that can handle the basic programs that you use in the same versions that you're using them, so that if something happens on one, you can easily switch and continue working as you resolve the other issue. One last thing on this in terms, and this is kind of an umbrella experience related to everything that I'm going to talk about here. So I just use the default themes and configurations. I don't usually customize my software that I'm using. Some people really get into that. I remember, you know, when I was younger, and there was a tendency to want to theme things and skin things and organize software. The issue with that is that once you have a crash or you have an upgrade or an update, now you have a whole lot of work that's really just based on pure aesthetics. Pick generic default themes that are good enough that satisfy your working environment, if you prefer light or dark, but take the default, whatever it is. And just that's it. I think it will save you a lot of headache in the long run. Just get used to whatever it is that you're looking at in its default form. And I tend to, I kind of set up my workflow around the default configurations. Unless there's something really nagging, I usually don't change the default configurations on any of the software that I use anymore. I just don't do it. The next topic is files. So first, we talk about system, redundancy with system. And now let's talk about redundancy with files. So here's a little story. When I was in graduate school for music, I went to grad school for music composition, so I was writing. I was working on my thesis work, which was going to be about a 30-minute long suite, a symphonic suite. And I was a good ways into it after several months starting the program. And at the school, all of the students, even the graduate students, had a requirement to attend a certain number of student and faculty recitals. So I was going to get in my quota and go to something that evening, and I was in my working room, my practice room, where I was writing and playing on my main instrument. And I had my computer open, and I was working on stuff, and I was sitting there, and I decided I would run out and go to, you know, a 30-minute recital. So I just go down the hall, into the recital hall, and I attend the recital, and after it's over, I come back to my room, and my computer was gone. So it was stolen. Someone had stolen it. And I never imagined that that would happen in that environment. It was very, very bold. The problem with that is that in those early days, redundancy in cloud servers weren't really a thing. You know, I was a fairly young graduate student, and I didn't have a lot of resources. I just had the main machine that I was using, and I was saving stuff largely to hard drive. You know, and it was very early in the project. Even though I had gotten a lot of work done, it was early enough that I wasn't making copies of anything. It was all kind of just single files, and I was saving them to a folder in the program's drive on the operating system. And it was all gone. So I had no way to get back to where I was. I had to start over. I was months into this, and I had to start over. I was nearly a semester into it, and I had to start the whole thesis over, and it all worked out. You know, I rewrote everything as best I could. I changed stuff, did new things. I couldn't recall some of it. More to the story, though, is about six years later, I was well out of graduate school, and I was working. I got a call from the state police, and they said they had recovered my computer. I had made an insurance claim on it, so I couldn't take the machine, but they did allow me the opportunity just to take a look to see if my work was still on it. And lo and behold, six years later, my files were right where I left them in a hidden file in the hidden folder in the program's folder in the operating system. So I actually got everything back. It just didn't matter anymore because I was way past that program and well into my career. But what's the lesson here? Back things up. I remember after that happened, I talked to a professor who was a literary professor. He's a professor emeritus on campus I was doing some work for, music composition work for. And he said when he was doing his doctoral work, he would keep copies of his thesis everywhere. He would run off copies, mimeograph copies that he would keep in his, he said he kept one in the trunk of his car. The moral of the story is save to multiple locations. Now the nice thing is that today we can save to cloud servers. You can save to some kind of cloud service, and there's a lot of free ones. And you want to save to a cloud service, I think, because there's already redundant backup. So you could have things locally on your drives, but then you could have the relevant important file saved to cloud service. And you don't really need to do anything else because those cloud servers are usually backed up themselves. You will, there's no chance of losing that data. So I saved to Google Drive. I mean, I just use my Gmail accounts. I have a few Gmail accounts that I use for different things. And I've got one really that's dedicated to composition. And I save my major files to that Google Drive. So 15 gigs free. What I do is I'll save to that, and then I will eventually clean it out after the project is finished. And then I'll publish final work to audio.com or to Bandcamp. I have a Bandcamp account. And these are places where there's free unlimited upload. And I can always download to get it back if I needed to. I can always get the work back. So I saved to a couple of different publishing sites. Those are two good ones, audio.com and Bandcamp. And then I save to other types of memory. You can save to flash memory as a redundancy and then, of course, to hard drive or to an external hard drive or whatever. But cloud services are usually the way to go. I save at least rendered audio in MIDI files to cloud service. So for me, that's notation files. So I'll save notation files and rendered audio files. Some people might want to save project files for DAW. Now, that can get a little complicated because usually the DAW project files will include many pieces of audio, which can be very, very heavy in terms of memory. You got to do whatever is most efficient for you. With the way that I work rendering from notation software, I can really just get away with saving the notation files and then just the rendered audio. Without too much trouble, I can get back into the project mode and work from there. And then I save my DAW projects. Usually I will save only the one DAW project to the system hard drive. And when I get to a certain point where – which happens usually very quickly after picture lock. When I get to a certain point where things look pretty stable, you know, it's usually days for that to happen after lock, I will save that to the cloud server. It takes up a lot of space, but I'll save that and I'll keep that there until it gets upgraded or updated, and then I will replace that file. So you just have to think ahead and save the necessary elements. If nothing else, save rendered audio. If the zombie apocalypse happens and you lose everything, at least you'll have the audio – rendered audio files that you can tweak in an audio editor, at least as a starting point. So make sure that you're doing that. Create new files rather than edit old ones. So this is another concept that I think is very helpful. It's going to – and you'll end up having a lot of files, but it's better to do this for reasons we'll talk about in a moment. Whenever you're creating an edit of a previously composed iteration, copy that file, rename it, and then edit it. You want to preserve history as you're going through the project and getting feedback and creating new material, okay? So make a copy of the file, rename it, and then edit that one and keep doing that in a chain as you go along. That's a very, very, very good practice. Also, include timing in the render. So if you're at a point and you're at picture lock and you have time code – we talked about time code recently – make sure that you're including the time code references in the files themselves in the name. If you're not doing a broadcast wave that has metadata with the time code in it, put the time code in the name of the file. That way it's easily recalled and organized if something bad happens. You can easily get things plugged back into a new project. And then the last thing is discard clutter and junk files. So you're going to have to be discerning. It can be easy to just save everything, but you will realize as you go through a project that some things really are not useful. They're so early in terms of their history and so incomplete that you can really just discard them and be sure that you're doing that. Try to keep a tidy space, tidy digital space. Discard stuff that is not useful. The last topic is project organization. So this is not really about redundancy but on the organizational side of it. So part of the redundancy has to do with organization, but this is really all about your projects, either your digital audio workstation project or your notation project, whatever you're working in, maybe your video project or an audio editor project. Number one, use a system. It doesn't matter what system it is. There's no right or wrong way to do this. For me, I usually use some kind of quasi-symphonic score order. I usually work in score order, symphonic score order, but I will usually go highest to lowest in families, which isn't truly symphonic score order for all sections, but that's what I usually do. I'll go highest to lowest in families and those families will be organized in score order in whatever project I'm doing. That's if I'm composing to notation software or to DAW. Once I get to the edit of the picture and I'm syncing final renders to a locked picture, that's a different story. I'll usually work by scene and it will be chronological. So the first cue will be on the top and as the project goes along in time, the layers will descend to the bottom. So I usually work in that way because you can always scroll down to the next section and then I keep cues that are related or elements of a cue that are related together in space. So you don't want to have tracks widely spread apart that are on the same cue. You want to have things that are organized in the same space next to each other for the same shot and the same scene throughout the project. So have a system. Use a system. It can be your own system, but have one. And this is also helpful, at least in terms of writing a musical work in notation or in DAW. It's helpful to do this because there might be a situation where having stems is warranted. If you have a thick symphonic score or if you have a lot of percussion layers or something like that or synthesizer layers in addition, if it's a hybrid score or something, your filmmaker might want to have some kind of stem separation. So if you're organized, it's easy to get stem separation. So keep that in mind. It will make life easier later on when you get to the very end of post-production and they're ready to synchronize the parts. They may ask for those stem separations. Label your tracks. I know this is kind of a pain to do, but take the time to put labels on the tracks and keep your labels simple. Just keep them related. Keep the labels simple. Put a name on it, you know, and some kind of association between the tracks that are related to each other in the project. Make sure that you're using labels on the tracks. Last also on this is to use the mute function on older renditions. So let's say you update a segment. You're at picture lock, you're way at the end of the project, and you've done a second version of a cue. Put that rendered output into a new track in the mix and mute the old track, but don't delete it. And don't necessarily create a whole new project just because you did that. Keep the same old project, but bring in the new cue, put it next to the old cue, and mute the old cue. And the reason for this, the reason for doing this for preserving history, is because filmmakers often lean back on previous iterations. As a musician, you're going to have times where you say, this idea makes musical sense. And the filmmaker will say, I want you to try something different. I want you to try this. And you'll say, okay, sure thing. And then you do what they ask. And they'll listen to what you've done for them. And then they'll say, eh, you were right, I like the old one. So don't make things complicated for yourself. Always save previous renditions, at least a couple renditions back. If you're having a lot of, you shouldn't have a whole bunch of renditions of one cue. I mean, you shouldn't be, it shouldn't be that complicated. But if you have, you know, three, two or three different versions of something, make sure that you have them all in the same project file and just use the mute function. Mute that track and preserve it. Keep it there. Because you might want to come back to it. You don't want to have to realign timing and recreate. Or, you know, you don't want to get to a place where the filmmaker says, hey, I kind of liked what we did three versions ago. It really seemed to be the best version of it. And it really grew on me. You don't want to have to say, oh, well, I've edited this file so much, now I have to go recreate what I did and try to do it authentically. You know, you don't want to have to do that. So, always save iterations and just mute them and then add to it. It's okay if you have a very, very deep and thick set of tracks. As long as it's organized, it really doesn't matter. Okay. So, quick recap. Redundancy. Have a redundancy of system if you can. It's a bit of a luxury for some people. If you can do it, have more than one system with at least the general same core architecture and the same basic software that you use in libraries that you use if you're using particular libraries more than other sound libraries for samples or synthesizers or whatever. Be careful about upgrading. Don't upgrade in the middle of a project. Always use, you know, longer term service releases. Don't use the new and shiny things just because they're new and shiny. Wait. Wait until the patch release where it's very stable and you're hearing reports about the stability of it and then investigate the new software and do it at a time when you can afford to spend time on it. Don't do it in the middle. Files. Make sure that you are saving multiple to multiple locations, particularly to cloud servers now. There's a lot of different options there, some paid, some free. It doesn't have to take up a lot of space if you're being picky and choosy about what you need to save. Just save the things that are really necessary like notation files and project files and rendered cues, final renders. Save those things to cloud server. Once you're done with the project, you can clean out your cloud server and then publish it to a publishing site like audio.com or Bandcamp. There's other ones out there, too. Some of them are free. Some of them are paid. But if you do that, then you'll always have a good cloud save location, not only where it's shared but where you can get back to it if you ever need to get back to those final renders. Any other project files you want to keep, save them to a hard drive or a flash drive or some other location. Or if you're paying for cloud service and you have a lot of it, you can save the essential elements to those locations. Create new files rather than edit old ones. If you want to drastically change something, don't just drastically change the file you're working on. Save a new copy of it, rename it, and then work from there because you always want to preserve the history as you go on. And then the last thing, project organization. Have a system. Have a system. Use an order. Be diligent about naming and labeling various tracks and sticking to your system. Don't get caught up in themes and colors and all that sort of thing. It's really about the naming and about the organization. That seems to be what matters the most. Do that. And always keep older renditions in the final edit. Just use the mute function to get out of the way. Double-check before you do final renders so that you're not rendering multiple iterations on top of each other. Just be aware of that. One thing I've done in the past was really complex. One thing that I've done in the past with complex projects is if I have a lot of iterations in there, I'll save a new version of the project and then I will delete all of the unused iterations and then I will render my final cut from that. But that's a choice that I make at the very, very end when I'm doing no more editing. I don't merely delete all the things I'm not using in the one project file because you never know. You never know. You could get past picture lock and past wrap for everybody and the filmmaker says, you know what, I still have a week to go before release. I think I want to revisit this. You want to be able to revisit it, right? So make a new copy where you'll delete all the stuff you don't need, render from that, if you want to try to keep things very safe and secure without making mistakes. So the preservation of history really is important, not just for the filmmaker and for you and your relationship and the possibility for change, but also just for history's sake, you may want to revisit things way down the line. I've had moments where I've revisited music I've written a decade before and I wanted to change its instrumentation. I wanted to adapt it to another kind of format or I wanted to change it and alter it in some way or improve it or borrow from it. I might want to borrow elements from that and be able to get it into a new project. So save your history. History is really, really good to have. History is important. You learn from your history and you depend on history and sometimes you have a desire to return to history, so make sure you save it. So those are my recommendations on organization and redundancy. I wish you the best of luck and happy composing.
There are no comments yet.
Be the first! Share your thoughts.
