Nabeel Ansari

You'll find Logic's default instruments don't really cut it for orchestra (no DAW has good orchestra samples, because good orchestra samples have a level of programming DAW-default samplers aren't really equipped with), but you should still test them. If you hear for yourself why they're bad you'll be able to discern "good" sounds with a better perspective, which is generally an important skill for a computer composer whether he/she's using it to produce music or he/she's using it to judge different libraries against each other.

The funniest aspect of your post is not anything you said, but the fact that you pretend you know anything about what you're talking about.

I mean, yeah, I also upgraded. W8.1 to 10. I still would recommend people to just start fresh, since the problems that can arise from upgrading gives people a false impression that Windows 10 is broken. Then we get people running around saying "STAY ON WINDOWS 7 THERE IS NO FUTURE FOR US" Almost all major VST's are compatible with Windows 10. I use Komplete products, Omnisphere, Zebra, Serum, Diva... actually, that's all I use pretty much. Got rid of PLAY, tried the Composer Cloud and just didn't want to spend the money for instruments I rarely used. I used to use a lot of small throwaway plug-ins but I ended up wanting to be in favor of smaller sets of bigger plug-ins. It's easy to work in-the-box and remember what to install on a new computer if it's just "Komplete, Omnisphere, and my other synths" rather than a bunch of small synths, ep's, harpsichordds, etc. Come to think of it, I'm due for a reformat to get all that extra stuff off! But as for smaller VST's, from indie developers, it's not guaranteed, yeah. What smaller VST's are you concerned about? You can send them to me and I'll try them out on Windows 10 and I'll let you know what breaks.

Upgrading an OS is generally always less clean of a process than starting from a blank slate. For the people more intent about maintaining their computers, it's actually kind of silly since they're so used to backing up and reformatting anyway that doing so for a new OS just seems like some extra dessert to add to their next deep clean (and upgrading is a messy task to deal with in light of knowing that a system wipe is incoming down the line anyway). I vote another for Windows 10, it especially improved Studio One performance for me.

Jesus am I getting old? The Storm Scout and the Antec 300 are nowhere to be found on Newegg anymore but also the site seems broken right now? The latter was just a generally solid popular case, and the former is my case that I've had and loved for the last 4.5 years, especially with its handles and the cool-ass warped window shape. Anyways, the HAF is a solid choice that seems to still be around , and super popular. Most commercial composers have machines with either 64GB or 128GB, along with slave machines hooked up over ethernet with VE Pro serving them samples that are processed off the main computer but (whose output audio is) still transferred back fast enough for real-time playback. Don't get confused either, VE Pro is by Vienna Samples, but it's not just for their products. It's a networking host system that you can load VST's in and set up the MIDI communications over network.

I'm not sure what "high-quality" libraries you're using, man, I frequently max out my laptop (8GB) with just a couple instances of Spitfire Albion. Things like Ilya Efimov nylon straight up take 1GB. I was live arranging on the How to Remix panel at MAGFest using my laptop and I had mistakenly forgot that my page file was set off. My computer crashed TWICE and needed reboots during that panel because I kept smacking it with sample libraries. I have 32GB on my main computer and I have way more breathing room. For "high-quality" samples, I recommend no less than 16. I work in sample libraries, so trust me on that. Additionally, there's some really bad misinformation about building computers here. Building computers is much cheaper than buying pre-built ones. They're more reliable, they last longer, and they're more upgradable, which translates to insane savings down the road. If you can't build it yourself, there are people you can ask, as well as local tech shops and even online custom build companies. There's no one on OCR who can give you better computer advice than prophetik (also called prophet). I'll ping him to swoop down here. He does custom builds and you can order from him. He does good work, picks the best parts, thoroughly tests the computers and does very good cable management and ventilation and all that.

I have a rule for people getting started, and that is don't get caught up in what's the best and what sounds like it has the most value (features, sound quality, etc.) When you're getting started, you need a baseline. The baseline is the set of instruments (or even just one library, like Albion, Symphobia, EWQLSO) that you learn how to use and you're "set". Meaning you can write orchestral music using them, and that's your fallback level of quality for mockups and such. Your baseline can be feature-rich and detailed (the Hollywood series) or incredibly dumbed down and easy to use (like ProjectSAM Orchestral Essentials). Once you have your baseline, and you are consciously feeling like "I'm trying to write music with a certain sound but my current set doesn't let me do it, but that other set will", only then should you start buying more libraries. For instance, let's say my baseline strings are CS2. CS2 is amazing, but it has no divisi. If I'm working on something and I need to write divisi, that's when I'm able to justify buying a library with divisi (like LASS or NISS). If I like to centerpiece a violin in my orchestra, I invest in a solo violin like Embertone Friedlander. NEVER BUY SAMPLE LIBRARIES OR INVEST INTO FEATURES BECAUSE YOU THINK YOU'RE SUPPOSED TO HAVE THEM OR "MIGHT USE THEM LATER ON". This is a slippery slope that never financially pans out in your favor (it may creatively, but I only give practical advice). You end up buying a metric ton of shit you never use in your music, and keep buying more when you get excited about new releases from your favorite companies to build up your "library". Don't "build up your library". I took that stance with purchasing stuff and I have bought so many thousands of dollars worth of tech I don't use and rarely have ever used outside of a single project. It's one of my biggest life regrets, actually, to be tangentially dramatic. It burns mostly because most developers employ a no resale policy, so I can't sell something when I'm done with it. It digitally follows me and stays on my Kontakt drive forever, and ever, and ever, and ever... Start with your baseline, and buy something when your baseline doesn't cut it. As you absorb more stuff into your baseline, you use it more often because it's the sounds you really wanted, and it becomes your new baseline. That's why amazing computer orchestrators layer different libraries. They didn't learn "layering tricks" from Daniel James on YouTube then go out and buy 3 different string libraries to stay in the game; they went through the grueling process of deciding their current libraries weren't giving them the sound they wanted, then visiting the market to find who developed a library for it.

I'm quoting this.

I highly recommend Spitfire's Albion ONE. It has simplified orchestral ranges (high, low, mid for brass) for each family, but this is only an issue if you're trying to create extremely delicate orchestration and/or arranging mockup for live performance. Besides that, it's got plenty of very well-performed articulations, good quality legato, and a killer natural wet sound from the further mics (which you can turn off). Spitfire records in a really amazing hall. It also has some really nice percussion, including "epic" stuff, and a lot of other sounds and loops using the eDNA (their cinematic synthetic libraries) engine. As for the DAW, I find Studio One to work best for my orchestral needs. It's got a lot of no-brainer MIDI editing features with CC, automation, etc. Super fluid. Cubase is also really good at this.

I don't think it's the phone mic at all; I think it's probably the saturation of the live sound system (speakers, or whatever's going on in that venue).

I personally disagree. In my time tutoring people who have trouble in Intro Programming (and other subjects), the issues often stem from an application of "little knowledge is worse than no knowledge at all". In other words, their professors and/or classmates explain things to them in ways that don't agree with their personal level of understanding, and their brains get sidetracked trying to reconcile the explanations they've received with what I'm trying to tell them (rather than simply learn the concepts fresh). I then first have to dismantle the things they thought they have learned before reteaching (then I send them off and they get A's or whatever). A poor explanation of something can in fact damage your ability to learn it, even if someone offers something complete and correct after the fact. This is true in a lot of disciplines (I have seen this personally when helping people with not just programming, but also math, physics, martial arts, and music). It's the reason why we have a saturation of mediocre people who can write decent programs (and even more who write awful ones), but not a lot of people who truly "get it".

@Kanthos We're already in mutual agreement about what C is for, I don't see the need to continue harping on this point. No one is suggesting to offer audio-related examples, nor is anyone attempting to design an intro to programming course. But regardless of whether useless examples are effective or not, creating examples analogous to real situations is possible, easy, and just takes some thought. It doesn't need to be complicated. Here's a small one. You type in a score from 0 to 100, and the program must spit out your letter grade. Simple, but within the parameters of real life, and something people actually do without the assistance of computers. That also makes it incredibly easy to debug, and incredibly easy to show how to break when you write the conditionals incorrectly. That's because the student already entered the program with the foreknowledge of understanding how to solve the problem using simple mental steps. He doesn't have to learn the constraints of the problem itself along with learning how to solve it. That kind of stuff can come later, when he's at the point where he knows how boolean logic works, how to make the computer do things by making decisions is controlling flow through loops and whatnot. # retrieve input, put into variable called 'score'. I'll stop at C/70 to be brief.if score >= 90: print 'You got an A!'elif score >= 80: print 'You got a B!'elif score >= 70: print 'You got a C!'# This is intuitive enough, but the problem with this is when we write it differently:if score >= 70: print 'You got a C!'elif score >= 80: print 'You got a B!'elif score >= 90: print 'You got an A!'# This seems the same to a beginner, but it's actually way wrong, because the structure terminates at the first condition when the score is 90.if score >= 70 and score < 80: print 'You got a C!'elif score >= 80 and score < 90: print 'You got a B!'elif score >= 90: print 'You got an A!'# This has the same order as the incorrect one, but now demonstrates how conditions can be made more specific using compound boolean logic.if score < 80 and score >= 70: print 'You got a C!'elif score < 90 and score >= 80: print 'You got a B!'elif score >= 90: print 'You got an A!'# Now we just simply reversed the order of the boolean conditions, and all of the sudden we can now talk about short circuit evaluation. That's a lot of concepts demonstrated by doing variations on something real world and simple. When the first example is run, the student gets a result he was looking for. When the second is, he immediately just knows it's wrong, without someone telling him it is or being arbitrarily specified in a textbook problem. I can keep going for days if you want me to, for as introductory or advanced programming concepts as you want (advanced within my knowledge). The reason why Timaeus's example was ill-placed is because first of all, you explain conditional loops before count-controlled loops, because count-controlled loops are special conditional loops (also his conclusion that while loops are somehow inconvenient because of having to know exit conditions is really bad advice and demonstrates poor understanding of a really simple concept and general lack of programming experience). Secondly, a conditional loop was appropriate for the kind of task Metal Man was looking for. He presented repetitive conditional code, and asked "how does this work within the logic of a loop?" And well, first step of teaching someone effectively is answering their question, not dodging it and pulling code from a textbook. All again, why I said this forum is not the place to learn programming. Too many different backgrounds and not a standard level of rigor for all the people allowed to post. I'm not even sure this thread is relevant to this particular forum anyway.

1. I specifically am talking about this task, in the context of file system scripting. The tool for this job is not C. The tool for this job is rarely C; the use of C is motivated by the need for low-level functionality and/or the in-line assembly stuff. Doing file scripting in low-level functionalities is not only a pain in the ass, it takes longer to write more advanced scripts and it affords a level of control you don't really need if you're literally just renaming files or printing directory lists. If you're scripting, using a scripting language is 9 times out of 10 more appropriate. But I think you agreed with this in your anecdotes. 2. In my experience teaching beginner's programming (quite a great many years), irrelevant tasks confuse beginners more than they help. That's because on top of learning the logic of how the program does its task, there's the compounded need to understand why that logic is necessary (because it's what the program is trying to do, the motivation for which is non-intuitive). I understand you may have gotten the example from a text, Timaeus, but texts are written by people, and a great many people can be bad at programming, bad at teaching, and also bad at both. (Usually just bad at teaching). Offering relevant examples isn't that much harder than irrelevant ones, and it makes learning easier for the... learnee? You get the point. Yes, but he's not trying to guess a number nor does he need to update a range of values to guess in. He's simply trying to double or halve C until it is within the range he wants (which is a static range that does not update). It's akin to shortening a name until it can fit into something.

Timaeus, your code isn't relevant to the task he's trying to perform. Additionally, your program makes no sense and isn't really applicable as a teaching tool since it does a task no one would ever actually do (give a computer a number and then have it randomly try to guess the number... when it already has it). Here is a cleaner one, Metal Man: #include <stdio.h>#include <stdlib.h>int main(int argc, char *argv[]) { double A = 15, B, C; const int MIN = 50, MAX = 200; printf("Tool to find the tempo in phase with the period of a frequency \n\n"); printf("Hz: "); scanf("%lf", &; C = A*B; while(C < MIN || MAX < C) C = (C<MIN)?(C*2):(C/2); printf("BPM = %.10f \n\n",C); getch(); return 0;} The golden rule in programming is Don't Repeat Yourself. This shouldn't be violated when designing software architecture, and it certainly should not be violated to the point where you write literally the same code over and over again immediately on the next line. Anything that should be repeated can be solved with either conditional loops, count-controlled loops, or recursion. I've here used a conditional loop ("is C not where I want it to be?") and a looped action to act on that condition. The action is to set C equal to C * 2 if it is less than 50, and C / 2 if it is not. Since the loop condition is already predicated on the fact that when you are inside the loop, C is either less than 50 or more than 200, than the simple assumption you can make is that C NOT being less than 50 means it IS greater than 200. If this is hard to grasp, I do recommend you take a course on programming, or contact me privately I can teach you programming concepts. This forum isn't really the place to learn programming.

C is not a scripting language. You need to compile C programs, and that's incredibly inconvenient if you do scripting on a regular basis. Recommending C for scripting is a bad recommendation. JavaScript doesn't have whitespace termination, so if you want to write bad code and still have it work, you can use JS no problem. There's no need to resort to low-level compiled languages for tasks like file organization.

I don't really follow, unless this is a VB thing where file names are not case-sensitive and thus you are unable to directly change the case of the letters in the filename. If that is correct, then you should move away from VB immediately. It is not a language designed for scripting and automation. Your code takes several orders of magnitudes longer to do tasks that are actually kind of trivial. Here's why. Let's say I want to run a capitalization, your way. Let's say there are 26 characters (just for example) that are eligible for capitalization. Let's say we want to run this on 500 files. Each name is 32 characters long. By your method, we create 52 for loops that iterate over every filename, replacing each instance of the substring character with a dummy character, then changing the dummy to the correct character. Note that this is bounded above by 52 * 500 * 32 (find-and-replaces) = 832000 loop iterations. If we increase it to 64 eligible characters, and say, work with a large number of files (like samples) such as 20,000, it becomes 81,920,000 loop iterations. That's wasteful, and also kind of gross (pun intended) from an analytic standpoint, since your runtime grows directly proportional to two separate independent variables. By a more efficient method, we write a nested for loop. One to loop through the files, one inside to loop through their names. Now we're simply upper bounded by the number of files and how long their names are (which makes more intuitive sense). For every character we encounter, we check if it's Unicode value is in a specific range (to see if it needs to be capitalized), then subtract 32 from its value to make it a capital letter. Now we're bounded in loop iterations to (note how the number of characters that will be capitalized has 0 effect on the computation time): 26 eligible capital characters: 500 * 32 = 16,000 (vs. 832,000) 64 eligible capital characters: 20,000 * 32 = 640,000 (vs. 81,920,000) That's a 98% and 99.2% reduction respectively in loop iterations. In other words, your code takes ~50 times longer in the first case and ~125 times longer in the second than it needs to do the operations. What's more is that this new method isn't really limited to a simple repetitive copy and pasted procedure. You can add more conditions for what ranges of characters should be treated how, right inside the body of the one loop. Your code is now also maintainable. If you want to add or change something, you do it once, not 200 times.

But I did that too

Yes, I was wrong to say all of OCR is on the same encodings; however, the essence of what I'm saying is that a better DAC will not really yield any perceivable difference on mp3's. Subtleties are literally erased (that's how it compresses so well), so they can't be heard.

There's no need to write your own capitalization functions, they already exist. They're also much more efficient than how you write these. Secondly, if you want to write your own, you need to do them efficiently. This means not writing an insane amount of for loops for something you can do in just a few lines of code. If you wanted to do a brute force character replacement, you don't need to interact with strings. Just add or subtract the Unicode value of the character in question (the distance between lower and upper cases is 32). So you just need to loop through the characters, check if it's within a certain range, and then adjust it based on whatever it's supposed to be doing. I don't understand the motivation to switch things to ~² before switching them to what they actually need to be. It seems like you're literally doubling the runtime of your program for no good reason, and it's already magnitudes larger than what it needs to be, considering you're running hundreds of for loops when you only need to run one. For example: If I want lower case characters, then I loop through my string (ONCE), check if the character value is between 0041 and 0060 (in hex, which is 65 and 96 respectively). If it is, add 32. (Likewise, you can figure out how to do it backwards). The same goes for these accented sections, they're the same distance. You may have to do a little digging to figure out how to actually accomplish this in VB. I can't help, because I don't use VB. I also don't recommend using VB for anything. It's quite honestly a horrible language, especially for scripting. Use something like Python or JavaScript, it's much easier to do pretty much anything than in VB. I'm sorry if I'm being harsh, but it would benefit you to take a free course on programming or utilized other kinds of free resources for learning. There are plenty, like Coursera, Udacity, CodeAcademy, Khan Academy, etc. Here's some examples in Python: import os, sys# Capitalize all files in current directoryfor f in os.listdir(sys.path): os.rename(f, f.uppercase)# De-Capitalize all files in current directoryfor f in os.listdir(sys.path): os.rename(f, f.lowercase)# Replace all underscores with spacesfor f in os.listdir(sys.path): os.rename(f, f.replace('_', ' '))# Make treefout = open('Tree.txt', 'w')for root, dirs, files in os.walk(sys.path): for f in files: fout.write(root + '\n') fout.write('\t' + f + '\n') fout.write('\n')

A DAC is a digital to audio converter. It's how sound from a computer turns from byte streams to an electrical current to be sent to speakers. A sound card has DAC's on it, that's how you plug your speakers into them. So first of all, no, you haven't switched to a DAC from a sound card, you've simply moved to a device with a higher quality DAC than your previous sound card had on it. Now that that's cleared up, any lossless music (WAV, FLAC, AIFF, etc.) will sound great run through higher quality DAC's. You will not find any of these formats on OverClocked ReMix's regular postings, but you will in many of the albums. mp3's sound worse on higher quality DAC's because it exposes the bad distortions that come from lossy compression. If you listen closely, it sounds almost like a combination of phasing and being thrust underwater. Furthermore, I doubt you're actually hearing that many new subtleties unless your previous sound card was ridiculously dysfunctional and/or noisy, especially not on mp3's, which are designed to remove a lot of subtle information from audio signals. This is because of perceptual effect, people are often tricked by their brains into hearing something they're not because of perhaps wanting to believe it or because it's their expectation. Yes, better DAC's sound better, but not even close to the degree you're making it out to be. Give it some time to normalize, and your ears (and perception ability) will smooth out. Finally, DAC quality doesn't really matter all that much if your speakers are bad, so if you want better sound, you should probably look into the transducers actually making the sound for you (the speakers, or headphones) before you start taking your new audio output device so seriously. All music will sound better with better gear (except if it's lossy compressed). There's not really any particular tracks that can be recommended for this. All OCR music is on standard encodings, so it won't really vary from track to track.

Authorization =/= execution Well, not really, see my quote from Wintory. Union voice talent isn't really irreplaceable, and the residuals demand is ridiculous in the face of the rest of the industry. Game publishers will see that one point and cut off the whole deal, because they don't want to pay. It's going to be the same deal as the AFM unless SAG-AFTRA drops the residuals demand and focuses on just fixing the working conditions. If they can do that, they can set a precedent for being the first (successfully) unionized game talent, and then we'll start seeing more people organizing.

I really want to get TH-2, people say it's great for hi-gain tones.

One instance of IBZ will kill all your RAM if you're using 32-bit FL. You need to bridge it.

It's not a synth, it's a sample-based instrument.

The problem is music/voice unions and such have little to no bargaining power in the game industry, because music/voice (performance audio, really) are the only unionized disciplines that appear in game development and production, and even so, there are plenty of (extremely talented) non-union artists and performers. They can't reach to any fellow unions to put pressure, because... well, there are none. Just look at the AFM fiasco with Austin Wintory. AFM didn't get what they wanted, so they made their own union members suffer for it. The game industry didn't like the terms that AFM had put up, because from their perspective, those kinds of demands were ridiculous and they had never seen them before. After all, everyone else doing programming, art, and whatnot aren't part of a union and are just subject to whatever their workplaces throw at them and this includes the publishing economic system in games that SAG-AFTRA is trying to fight (and AFM was trying to fight before them). In their eyes, why should voice actors be any different? The exception would seem unfair from the outside, and of course there's the obvious factor that they would lose money. Now, that is a bad thing, yes. More disciplines in game dev/production need to be unionized because working in the game industry is pretty awful, working condition and quality of life considered. But as it stands right now, there isn't enough there for SAG-AFTRA to succeed in a standard union negotiation type deal, so their approach is... well, inefficient. That's because the AFM is run by someone who doesn't understand the game industry. Mr. Austin Wintory himself: