I think the onus is more often going to be on the audio guy to bridge the knowledge / language gap with the programmers because most of us will probably have been forced to get familiar with a range of technologies just doing our job (maybe building our own websites, setting up networks, all those non-music things we have to do), while most programmers will never need to know anything about music theory etc. It's worth mentioning that DirectMusic is actually a great way for the musician to learn that overlap in my experience. Before starting with DM the only kind of programming I had ever done was BASIC when I was a kid (long forgotten) and some HTML more recently. Not exactly good qualifications! But the AudioVB script in DM was easy to learn and helped give me some common ground with the programmers I work with. It also showed them I was willing and able to learn and that helps too. -----Original Message----- From: directmusic-bounce@xxxxxxxxxxxxx [mailto:directmusic-bounce@xxxxxxxxxxxxx]On Behalf Of Saul Bottcher Sent: 23 October 2002 15:36 To: directmusic@xxxxxxxxxxxxx Subject: [directmusic] Re: directmusic Digest V1 #47 Hi John, My two cents: cent #1: If you are designing sound or composing music for games, look at it this way - every game has a sound system and a music system. Whether or not you run into problems or challenges related to the way the system works, the systems are still there. So you should be able to speak fluently about the technologies which are directly related to music and sound. You shouldn't need to understand the exact processes involved in programming the sound or music system, but the more you do, the easier your job, right? cent #2: If you are a programmer working on a game and assigned to either the sound or music system, look at it this way - every sound or music system has a content creator (or several) working with it. Whether or not you run into problems or challenges related to their content and how it (ab)uses the system, the content creators are still there. So you should be able to speak fluently about the aspects of music and sound which impact the system's performance, or which could be influenced by its limitations. You shouldn't need to understand the exact processes involved in sound design or composition, but the more you do, the easier your job, right? bonus cents: Notice the overlap? I'd like to suggest that this is a necessity. Communication doesn't come from the edge of your "knowledge sphere" touching someone else's edge. It comes from having enough overlap that your ideas can fit inside that space you create. (Yeah, weird analogy). In an idealised version of the industry, composers would know a little technology, and programmers would know a little music, and that would be enough. But in practical terms, you're going to run into programmers that don't even listen to music, and programmers will run into musicians who are afraid to click on anything other than their sequencer shortcut. So it behooves both sides to learn that little bit extra to make sure they can mesh with anyone. Not everyone will take the time to do this learning, but the people who do are in my mind more employable and more likely to be seen as competent professionals. Caveat: Programmers aren't always assigned to the same tasks, so they may feel less pressure to learn about audio than you might feel to learn about programming, especially if you're a game-only composer r sound designer! (In other words, we may have the short end of the stick to a point). > has anyone else encountered this problem? I certainly have. I've worked for people with absolutely no musical knowledge, and doing revisions on songs can be excruciating. You should hear some of the bizarre comments I've received. I don't know if it would be too off-topic for this list to ask for more detail on the problems you're having. You could e-mail me if you like, I may have some useful advice, but at the very least some sympathy. :^) Either way, good luck working it out. Saul.