This is it! Week five. The final installment of my series on The McCarthy Protocols. I hope, if you’ve followed along, that these protocols have gotten clearer and clearer as they’ve been explained. There’s only two short protocols left. The Investigate protocol, and the Personal Alignment, arguably two of the most important protocols in the Core, and the latter of which is, in my own opinion, the cornerstone of what the Core is all about (hence, I saved it for last!)
You may have noticed these introductions have been getting shorter and shorter, and that’s simply, I feel, because the pieces are falling into place. It’s less explanation and more internalization – that’s kind of how this process works. It always feels really goofy and silly in the beginning, but as it comes together, it really cements the dynamic of a team together. As always, you can return to the very first introduction post here and read from the beginning if something doesn’t make sense, or click here to go to official online Core Document. Additionally, leaving comments and feedback is a welcome way to Ask For Help on using the Core, or simply talk more about it in general. – I really enjoy working with them, and have done my best to implement them with the various teams I’ve worked on since graduating college even a few short months ago. Anyway. Let’s get started. Read on!
Welcome to a quick overview of creating a Max/MSP patch. This is my very first tutorial on Max so it’s going to be incredibly simple. Any other Max Patches I create will likely show off something a little more complex, so experienced users might not find too much here for them.
Max/MSP (M.S.P. standing for Max Signal Processing) is an incredibly cool program developed by Cycling ’74, created by Miller S. Puckette (another M.S.P.!). It is largely considered to be a much more user-friendly cousin to Pure Data (“Pd”) , which Puckette also designed. Since I purchased it a month ago, Max 6 has quickly become one of my favorite toys, and is incredibly fun to design audio with. It is a Digital Signal Processing application, which means that it can process audio in real time. We’re going to take a quick look at Max to get a glimpse at it’s capabilities and create a short, extremely simple delay effect. To avoid repeatedly explaining anything, when I say to create an object, just hit “N” on the keyboard and type in the name of the object that I write in a quotes.
To start, create an “ezdac” object to create an output for your signal (a “dac” is a Digital-to-Audio Converter – a speaker(!) – and its inverse is the “adc”, the Analogue-to-Digital Converter – a microphone(!). You can use just a regular “dac” as well, but the ezdac offers a graphical interface). The interface of the ezdac is pretty simple. Click it to turn the audio engine on or off. The next step is to actually create the signal, so let’s create a new object called “cycle ~ 220”. “cycle” is a keyword to generate a sine wave. It is an oscillator. The tilde (“~”) is a signifier that the object deals with audio and not data – all audio-related objects end with a tilde. The 220 is an argument for the “cycle” keyword that specifies 220 cycles per second (a wave with a frequency of 220 hertz). If you were to plug this object into the ez-dac, you can hear – at your speakers maximum volume – a pure sine wave of 220 hz. To give yourself some control, create a “gain~” object and connect it between your ezdac and oscillator (make sure to connect all channels of the dac to the gain slider.
Now that we have something playing a tone, we’re almost ready to create a delay line, but because we have a single tone playing, any delay is going to go unnoticed, so let’s create a number box (hint! hit I on the keyboard to create a number (integer!) box!) and plug it into the “cycle~” object’s top inlet. The number box will alter the argument of the oscillator, so whatever number you place into the number box will replace the “220” in the oscillator object. The trick here is that you can click and drag on the number box and hear the delay line as your oscillator changes. It looks like this:
Now to start the delay line.
Create a “tapin~ 1000” object. The “tapin” creates a memory space for the last X amount of milliseconds of audio. In this case, we’re getting the last 1,000 milliseconds (1 second) of delay. Break the link from your “cycle~” object to your “gain~” object, and instead connect “cycle~” to your fancy new “tapin~” object. Now create a “tapout~ 50” object, and connect the out of “tapin~” to it’s input, and “tapout~ 50″‘s out to “gain~” input. The argument of 50 in the “tapout~” object is the actual delay being generated. You’ll notice that the connection between “tapin~” and “tapout~” is a data connection and not an audio one – this is no accident! Because “tapin~” is actually storing 1,000 milliseconds of audio, you can actually use “tapout~” to create several delay lines using one source. So adding arguments (for example “tapout~ 50 200 500”) might result in an interesting delay pattern. You’ll just have to experiment to find out!
One last touch: Multiplying signals is effectively the same as a mixing two signals together on an audio console. So if you multiply two signals, you just get both signals in one audio “line” (for lack of a better term). So, if you were to “mix” back in the delay, you could effectively turn your delay into a reverb! To do this, simply multiply your signal coming out of your delay and mix it back in before the delay again. Just create a multiplication object that will return 75% of the output back to the input. Create an object “*~ 0.75” and connect the out of “tapout” to its’ input, and the multiplication objects output to the input of “tapin” (If you were to create this as a variable range from 0-100%, it would be the same as a feedback knob on a delay pedal. I’ll leave that for you to figure out though!)
If you desire, you can copy this paste on pastebin to your clipboard and open it in Max 6 using the file>new from clipboard command, to see exactly what I’ve created. Additionally, I would like to credit Joel Rich for the original tutorial I followed to create this patch when I first began using Max. You can find that video here.
Week four! This series has now been running for a month! Is it weird to say I’m a little bit proud of myself at the moment? I know I don’t have a ton of readers yet, but even still, it feels good knowing that I can take something I learned and know it enough to the point where I can explain and demonstrate it to someone else. And after all, that is the purpose of keeping this blog: Showing to myself and to anyone watching that I know my stuff, through and through.
As always, you can return to the introductory post to get an overview of all of the protocols, and read forward from there. Or you can go to the Official Core online page and get an overview (and more) over there. If you’ve been following along (Thank you!), then read on. This week I’m going to cover three more protocols. They are, in my opinion, some of the most practical ones in the Core set of protocols, and are important to keep things moving fluidly in a given team. More decisions being made earlier helps turnover, and turnover means more gets done. These protocols relate to decision making.
Welcome back to Wednesday! It’s Week #3, so I’m covering a few more of those McCarthy Protocols! Like before, if you’re at all confused reading this, jump back to the very first post, the introduction, by clicking here. And, as before, just remember that protocols are the actions by which you interface with your team, and the commitments are the literal commitments to which the entire team abides by in order to create effective, efficient communication. This series of weekly posts is an analysis of these protocols and their associated commitments (as well as my experiences with them!), but as always, if you want to read the full “official” list, you can do so by checking out the Official Core Protocols document online.
It’s Wednesday, so welcome to the second post discussing the McCarthy Protocols! This is going to be quite a bit longer than the standard post, but welcome anyhow. I mentioned in Part 1 that my Game Project class used a variation of Scrum known as Scrum-ban with these protocols to organize our teams. Scrum-ban was the method in which we framed our work, and The Core [aka McCarthy] protocols were how we framed ourselves.
It may feel silly in the early stages, but using this method, you may soon find yourself being much, much more productive. So let’s dig into the first sets. Remember: The protocols are actions, and the commitments are the reasons and promises to the team upon which those actions are predicated. If you’re feeling a little lost reading this so far, or want to see the full list (it’s not long!) of the protocols and commitments, click here to read the introduction post.
They say if you can’t beat em, join em.
And if you can’t join em, just steal the uniform from the guards and pretend like you’ve joined em anyway.
In the game industry, it can sometimes feel like a catch-22. You need to have shipped a title or two to apply here, but as a college grad, I haven’t actually shipped any real titles that weren’t school work…Not yet anyway. I’m still inexperienced, so it would seem, and that is just one more thing in the plethora of things I’m going to have to overcome. Another of those things is “get hired in the game industry.” And while it’s a bit difficult to even know where to start with something as nebulous as “Become a kickass game sound designer,” I’ve learned to take a bit of comfort in the unknown. Sort of. It’s still pretty scary. Back in school at Columbia College, we had a phrase when tasked with something and not being sure where to start: “Just go kill Castro.” It was kind of tongue in cheek way of saying “Just do it.” You have your mission. It doesn’t matter how you do it, just get it done.
So with that said, I’m proud to announce that I’ll be spending some time with a second blog starting tomorrow, a development diary. It’s time to start getting things done. I’d like to direct your attention to the official blog of Team Lampyridae, a development team I have joined that was recently put together to produce the upcoming iPad/iOS game, Illuminate. It’s going to be sweet! A gesture-based iOS game in which you play as a firefly who…well…you’ll see in the coming weeks. I wont spoil the dev diaries just yet!
I feel good right now. I’d be a liar if I said I wasn’t feeling a bit lost now that I’ve graduated from school. School was an anchor for me. Get up. Go to class. Go to work. Do homework. Go to sleep. Repeat. Being an unemployed graduate is difficult, and eating through my savings to support myself for now feels unproductive to say the least. But I have a passion to work on sound design for games, and if that means it takes a minute to crack into the industry, who am I to sit around doing nothing? Let’s get to work!
Killing Castro might just be the most foolproof plan I’ve got, short of breaking into Bungie Studios and pretending like I’ve been there the whole time, cutting dialogue as they search for a localization editor for Destiny.
Alright. It’s time to tell the truth: While I will definitely be focusing on audio and game sound design in this blog, there is a ton more to game sound design than just creating sound effects and music. Teamwork is important. So it’s time to talk a little bit about functional teams, and a great place to start is in the world of agile development.
For those unaware, Agile development is a really neat paradigm which relies on creating self-organized, cross-functional teams. It emphasizes adaptability and flexibility in attaining long-term goals and utilizes many different approaches to create great software without being bogged down by heavy game design documents. The main advantage is that the designer of the software (in the case of a game) can “nail it and scale it,” as one of my former professors likes to say. The purpose of this adage is to allow the designer to find the fun aspects of the game and then build it up.
As part of the curriculum in his class, we practiced a method of agile development known as Scrum-ban, which is a product of the joining of the Scrum and Kanban methodologies. I will talk more about Scrum, Kanban, and Scrum-ban in another series of posts, but what I want to focus on first is the McCarthy Protocols, which were an awesome experience to have in the classroom. Whereas Scrum tends to focus on the team members and their commitments to the other team members, I find that the McCarthy Protocols are more directed to the securing the individual commitments of each individual team member to the team as an entity in of itself. There’s a lot to discuss about “The Core” – the commitments and protocols utilized to promote great teamwork. In a nutshell, it is made up of several named protocols and commitments – made to the team – which help deliver effective team communication and ultimately, good software. I will cover all of these protocols and their associated commitments over the course of a few posts.
For now, the these named protocols are:
Check In/Check Out
Ask For Help
The core commitments are:
To commit to engage when present.
To know and disclose
To know what I want, what I think, and what I feel.
To always seek effective help.
To decline to offer, and refuse to accept, incoherent emotional transmissions.
To immediately either propose for decisive acceptance or rejection (or explicitly seek the improvement of) when I have, or hear, a better idea than the currently prevailing one.
To personally support the best idea, regardless of its source, however much I hope an even better idea may later arise, when I have no superior alternative idea.
To seek to perceive more than I seek to be perceived.
To use teams, especially when undertaking difficult tasks.
To speak always, and only, when I believe it will improve the general results to effort ratio.
To offer and accept only rational, results-oriented behavior and communication.
To disengage from less productive situations when I cannot keep these commitments, or when it is more important that I engage elsewhere.
To do now what must be done eventually when it can effectively be done now.
To seek to move forward toward a particular goal, by biasing my behavior toward action.
To use the Core Protocols (or better) when applicable.
To offer and accept timely and proper use of the Protocol Check protocol without prejudice.
To neither harm—nor tolerate the harming of—anyone for his or her fidelity to these commitments.
To never do anything dumb on purpose.
If you can’t wait for the next post, make sure to check out the official Core Protocols document online. I hope nobody minds that I’ve modified the wording of the commitments for legibility. The next few posts in the McCarthy series will be published on Wednesdays, offering both my experiences with and critiques of the individual protocols and highlighting some of the commitments put forth by Jim and Michele McCarthy.
I hope you will enjoy!
– Chris Prunotto
There is an overview page set up here for these posts, or you can go on to part two by clicking here!